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This  Algorithm  Description  for  the  Global  Deployment  Analysis  System  (GDAS)  was  prepared  by  Noetics, 
Inc.  for  the  U.S.  Army  Concepts  Analysis  Agency  (CAA)  under  Contract  Numbers  MDA903-93-C-0259, 
DAS  WO  1 -94-C-0 170,  DASW01-95-N-5536,  and  DASW01-97-D-0126  with  the  Defense  Supply  Service 
Washington  (DSS-W).  The  Contracting  Officer  Technical  Representative  is  Dr.  Elizabeth  Abbe  of  CAA, 
who  is  also  the  principal  functional  sponsor  and  tester  of  GDAS.  Questions  about  the  GDAS  should  be 
referred  to  her  at  the  following  address: 


Dr.  Elizabeth  Abbe 
US  Army  Concepts  Analysis  Agency 
8120  Woodmont  Avenue 
Bethesda,  MD  20814-2797 
Telephone  (301)  295-0027 


GDAS  for  DOS  uses  the  Paradox  Database  Management  System  under  a  sub-license  agreement  for  the 
Paradox  Runtime  software,  which  requires  the  following  statement.  The  Paradox  Runtime  software  is 
copyrighted  by  Borland  International  and  is  covered  by  applicable  copyright  laws.  The  Runtime  may  not 
be  copied  without  permission  except  as  part  of  the  GDAS  installation.  Borland  International  is  not 
responsible  for  any  negative  effects  resulting  from  the  use  of  Paradox,  and  any  application  support  for 
Paradox  Rimtime  will  be  provided  by  the  GDAS  developers,  CAA  and  Noetics  Inc.,  and  not  by  Borland 
International. 

GDAS  for  Windows  has  also  been  developed  by  Noetics,  Inc.  with  modifications  to  support  the  Voluntary 
Intermodal  Sealift  Agreement  (VISA)  under  partial  funding  from  USTRANSCOM,  the  DOT  Volpe 
National  Transportation  Center,  and  Stanley  Associates,  Inc.  GDAS  for  Windows  uses  Microsoft  Access 
97  as  the  database  engine,  which  must  be  purchased  and  installed  separately.  GDAS  for  Windows  can 
import  the  scenario  data  from  GDAS  for  DOS,  and  both  applications  share  common  model  code  and 
scheduling  algorithms. 


Acknowledgements 


GDAS  could  only  be  developed  with  the  support  and  hard  work  of  CAA  staff  and  the  GDAS  programming 
team.  Key  management  direction  was  provided  by  Mr.  Daniel  Shedlowski,  Mr.  Frank  McKie,  and  Dr. 
Elizabeth  Abbe  of  CAA.  Testing  and  review  of  GDAS  was  supported  by  CAA  staff  including  Mr.  Jose 
imperial^  Ms.  Nancy  Daugherty,  Major  Ben  Herr,  Ms.  Renee  Carlucci,  Ms.  Vera  Hayes,  and  Ms.  Patricia 
Fleming  of  CAA.  Prior  program  management  and  testing  were  were  provided  in  a  previous  contract  by 
Stanley  Associates,  as  well  as  ongoing  testing  and  support  on  the  GDAS  for  Windows  software.  The 
GDAS  design,  algorithm  development,  and  programming  were  performed  by  Dr.  Stephen  Young,  Mr. 
George  Dalton,  and  Mr.  Keith  Hall  of  Noetics,  Inc. 


System  Overview 


1 .  System  Overview 


1. 1  Document  Preview 

This  document  contains  die  GDAS  Algorithm  Description.  This  initial  section  provides  an  overview  of  the 
GDAS  system  adapted  from  the  GDAS  User  Manual.  Subsequent  sections  summarize  the  data  structures  and 
model  algorithms  that  are  used  in  the  GDAS  software. 

1.2  GDAS  Summary 

GDAS  is  a  software  package  which  performs  transportation  analysis  of  large  or  small  scale  DOD  deployments 
including  mode  planning,  port  selection,  routing,  scheduling,  and  simulation.  GDAS  executes  on  desktop 
microcomputers  running  Microsoft  DOS,  Windows  NT  4  or  later,  or  Windows  95  or  later.  GDAS  incorporates 
a  global  transportation  network  and  schedules  movements  from  CONUS  origins  to  intra-theater  destinations 
using  intermodal,  multi-theater  transport  by  air,  land,  and  sea.  GDAS  components  include  integrated  database, 
query,  world-map  display,  chart  graphics,  scheduling,  simulation  modeling,  analysis  tools,  and  reporting 
rap^hjliti^c  Detailed  analysis  features  include  tracking  of  individual  ship  and  aircraft  locations,  shortest  path 
routing  with  node  constraints  for  all  modes,  port  facility  throughput  limitations  with  queuing,  integrated 
air/sea/motor/rail  mode  selection,  and  staging  of  time-phased  movements  at  intermediate  ports.  Use  of  GDAS 
requires  an  analyst  who  is  knowledgeable  in  DOD  transportation  and  can  understand  the  data  relationships,  but 
does  not  require  programming  expertise. 


Figure  1-1. Intermodal  Transportation  Network 
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Features  of  GDAS  include: 

•  All  modes  of  transport  are  treated  within  a  common  framework. 

•  The  system  provides  a  framework  for  testing  multiple  scheduling  algorithms  which  can  be  user- 
selected  at  runtime  for  each  mode  of  transport. 

•  The  scheduling  algorithms  explicitly  account  for  the  multi-modal,  interdependent  nature  of  DOD 
transportation,  in  particular  predecessor/successor  relationships  and  staging  dependencies. 

•  The  model  can  run  at  a  high  level  of  detail  or  a  more  aggregate  level  of  detail  simply  by  changing  data 
inputs. 

•  All  data  is  table-driven,  including  modes  of  transport,  units  of  measure,  vehicle  types,  vehicle 
compartments,  cargo  types,  etc.  and  all  of  these  can  be  changed  in  the  data  without  modifying  code. 

•  All  model  data  is  input  from  the  database  and  output  to  the  database,  visible  to  the  user. 

1.3  Why  GDAS  was  Developed 

Because  of  the  importance  of  DOD  mobility,  many  models  have  been  developed  to  analyze  and  simulate 
various  aspects  of  deployment.  These  models  include  MIDAS  and  JFAST  for  intertheater  air/sea  deployment, 
and  SUMMITS  and  ELIST  for  intratheater  transportation  flow  analysis.  Recently,  USTRANSCOM  has  also 
developed  the  Advanced  Mobility  Platform  (AMP), which  provides  a  framework  for  interfacing  with  several  of 
these  planning  models,  including  export  to  TPFDD  B-8  files  which  can  be  processed  by  GDAS. 

Within  the  context  of  these  other  models,  GDAS  was  developed  with  several  objectives: 

•  to  perform  both  intertheater  and  intratheater  mobility  analysis  within  an  integrated  framework, 
including  mode  planning,  port  selection,  staging  at  intermediate  ports,  and  shared  use  of  resources  in 
combined  operations  plans; 

•  to  support  more  detailed  analysis  of  lift  assets  and  facilities,  such  as  scheduling  of  individual  aircraft, 
tracking  of  hourly  facility  constraints,  matching  of  truck/rail  cargo  constraints,  and  setup  for  pre¬ 
scheduled  cyclical  liner  routes  and  preset  vehicle  itineraries; 

•  to  schedule  more  realistic,  balanced  force  deployments  with  proper  time-phased  delivery  of  related 
movements,  suitable  for  input  into  combat  models 

•  to  provide  adjustable  levels  of  detail  in  movement  requirements,  ranging  from  aggregate  totals  for 
quick  studies  to  individual  line  item  dimensions  for  detailed  analyses; 

•  to  provide  fully  integrated,  end-to-end  scheduling,  so  that  bottlenecks  in  the  theater  can  be  identified 
and  alter  the  planned  mode  and  port  selection  (POE,  POD)  prior  to  shipment  from  CONUS; 

•  to  provide  support  for  ad-hoc  queries  and  analyses  using  relational  database  capabilities; 

•  to  implement  large-scale  scheduling  and  simulation  algorithms  on  readily  available,  portable,  and 
increasingly  powerful  microcomputer  platforms. 

GDAS  was  designed  from  the  beginning  to  be  a  highly  detailed  model  for  multi-modal  scheduling,  and 
simulation  from  origin  to  destination.  The  relational  database  structures  are  designed  to  represent  the  complete 
transportation  network  using  common,  unified  data  structures  for  all  modes  of  transport,  including  lift  assets, 
vehicle  types  and  compartments,  facilities,  transportation  links,  routes,  movement  requirements  with  staging 
and  pre-positioning,  multiple  cargo  dimensions  and  quantity  measures,  and  scheduling  time/cost  objective 
functions.  By  using  completely  table-driven  model  inputs,  ranging  from  units  of  measure  to  transport  modes 
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and  vehicle  types,  the  various  algorithms  developed  for  GDAS  can  be  applied  to  each  mode  at  user-adjustable 
levels  of  detail  appropriate  for  the  study. 

An  overview  of  GDAS  system  components  is  provided  in  Figure  1-2  followed  by  a  summary  of  the  major 
subsystems. 


1.4  Database  Subsystem 

The  GDAS  database  subsystem  provides  view,  edit,  query,  and  report  capabilities  for  a  full  range  of 
transportation  data  including: 

•  movement  requirements  for  unit,  prepositioned,  resupply,  staging,  and  retrograde  movements; 

•  origins,  mobilization  stations,  theaters,  and  fmal  destinations; 

•  intermodal  transportation  network  for  air,  sea,  motor,  rail,  and  other  modes  with  node/link  constraints; 

•  aircraft  types,  compartments,  and  characteristics; 

•  individual  ships  and  ship  compartment  data; 

•  seaports,  berths,  and  port  constraints; 

•  airports  and  airport  constraints; 

•  various  scenario  data  such  as  attrition  and  convoying; 

•  detailed  scheduling  results  by  vehicle,  trip,  and  stop 

•  summary  results  and  delivery  profiles. 
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All  data  is  table  driven,  so  it  is  easy,  for  example,  to  define  new  ship  types  having  an  arbitrary  number  of 
compartments  with  individual  capacities  and  units  of  measure. 

Key  features  of  the  database  include: 

•  user  friendly  editing  with  either  tabular  views  or  single  record  form  views  of  data 

•  “help  and  fill”  lookup  screens  for  data  entry  without  typing 

•  comprehensive  edit  checks  at  the  time  of  data  entry  to  maintain  data  quality 

•  global  search  and  replace  for  changing  large  amounts  of  data 

•  automatic  propagation  of  data  changes  to  maintain  normalized  referential  integrity 

•  menu-driven  data  tables  and  data  entry  forms  with  pick  lists  and  edit  checks 

•  extensive  data  checking  tools  ( critically  important  for  any  study!) 

•  ad-hoc  query  capabilities  with  data  export 

•  chart  graphics  for  reports  and  queries 

•  output  reports,  analysis,  and  query  tools. 

Powerful,  but  easy-to-use,  query  capabilities  are  provided  simply  by  checking  the  tables/fields  desired,  with 
tools  to  perform  automatic  multi-table  query  linking,  define  record  selection  criteria  with  “help  and  fill”, 
perform  Boolean  selection  and  comparisons,  provide  on-screen  or  formatted  report  output,  and  provide 
presentation  chart  graphics  (stacked  bar,  multi-line,  area,  pie,  etc.)  on  the  results  of  any  query. 


Figure  1-3. Sample  GDAS  Database  Input  Forms 
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For  the  DOS  version,  the  database  capabilities  are  implemented  using  Paradox  Rimtime  for  DOS,  so  that  it  is 
not  necer  .  ry  to  purchase  a  commercial  database  package.  For  the  Windows  version,  the  database  is 
implemented  in  Microsoft  Access  97,  which  must  be  purchased  and  installed  separately.  The  figures  display 
sample  data  input  and  chart  output  forms  in  the  GDAS  database. 


rigure  ►  _ _ „ _ _ _ 
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1.5  Mode  Planning  and  Transportation  Scheduling 

GDAS  scheduling  algorithms  use  a  combination  of  data-driven  decision  rules,  mathematical  cost/benefit 
analyses,  dynamic  programming,  path  algorithms,  insertion  routing,  and  heuristics  in  order  to  plan  modes  of 
transport,  select  ports  (POE,  POD,  intermediate),  configure  cargo  (e.g.,  for  containerization),  and  schedule 
individual  aircraft,  ships,  and  motor/rail  trips.  The  detailed  scheduling  model  tracks  individual  trips  or  sorties 
for  all  modes,  matches  cargo/vehicle/facility  constraints,  loads  separate  compartments  with  multiple  capacity 
measures,  and  assigns  multiple  POE/POD  trips.  Scheduling  can  also  include  route  insertion  with  multiple 
pickups  and  deliveries  per  trip,  typically  used  for  sealift.  In  addition,  cyclical  liner  routes  and  pre-scheduled 
itineraries  can  be  specified  prior  to  the  model  run.  Simulation  techniques  are  used  to  generate  supply 
requirements,  model  facility  throughput  constraints  and  queuing  at  ports,  simulate  loading  and  unloading,  and 
calculate  travel  times. 

Because  of  the  large  number  of  decisions  to  be  made,  the  GDAS  strategy  is  to  break  the  overall  scheduling 
problem  into  major  subproblems,  which  are  then  solved  iteratively  at  several  levels  using  optimization  and 
heuristic  algorithms  based  on  user-input  constraints,  decision  rules,  and  cost  factors.  The  major  subproblems 
comprise: 

•  long-range  mode  planning,  which 
tentatively  assigns  ports,  modes, 
fleets,  cargo  configurations,  target 
lift  times,  and  target  delivery  times 

•  mid-term  cargo/vehicle  scheduling 
and  routing,  which  assigns  and 
schedules  (or  re-schedules)  specific 
vehicles,  trips,  stops,  facilities,  and 
cargo  loads 

•  current-day  execution  and 
simulation,  which  simulates  the 
actual  vehicle  loading,  unloading, 
facility  throughput,  facility  vehicle 
handling,  queuing,  surprise  events, 
etc. 


FOR  EACH  DAY: 

PLAN 

Assign  ports,  fleets,  modes,  cargo 
configurations,  target  lift  times  into  future 

SCHEDULE 

Schedule  cargoes  and  vehicle  itineraries 
forward  into  the  future 

SIMULATE 

Simulate  current  hourly  loading,  facility 
throughput,  queues,  travel  time,  etc. 

UPDATE 

Update  future  plans  and  schedules 
from  simulation,  add  surprise  events 

ITERATE 

Iterate  on  planning,  scheduling, 
simulating,  and  updating 

Figure  1-5.  GDAS  Planning  and  Scheduling  Process 

These  major  subproblems  utilize  the  solutions  of  other  more  localized  subproblems  which  are  solved 
separately,  including: 

•  route  insertion  for  a  candidate  cargo  assignment  in  an  existing  vehicle  route 

•  vehicle  loading  for  a  candidate  cargo  onto  multiple  vehicle  compartments 

•  port-to-port  travel  times  with  link  delays,  speed  variations,  routing  constraints,  etc. 

•  convoying 

•  facility  scheduling  with  cargo  and  vehicle  handling  constraints 
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1. 6  Modeling  Level  of  Detail 

All  data  is  table-driven  from  the  database  so  that  the  level  of  detail  is  adjustable.  Movement  requirements  can 
be  specified  as  aggregated  packages  with  total  short  tons;  or  as  more  detailed  packages  with  short  tons, 
measurement  tons  (a  unit  of  volume),  and  square  feet  by  unit  and  cargo  category;  or  as  individual  line  items 
with  both  quantity  measures  (tons,  square  feet,  etc.)  and  dimensional  limits  (maximum  height,  etc.). 

The  typical  level  of  detail  used  for  sealift  scheduling  includes  the  following: 

•  individual  ship  characteristics,  such  as  speed,  draft,  length,  beam,  cargo  dead  weight  capacity 

•  multiple  compartments  and  capacity  measures  with  stow  factors; 

•  multiple  pickups  and  drop-offs  per  trip; 

•  shortest  path  calculations  with  routing  constraints  for  canals; 

•  detailed  seaport  facility  modeling  including  constraints  on  draft,  length,  beam,  available  berths, 
queuing,  cargo  throughput,  load/unload  rates; 

•  matching  of  ship/compartment/cargo/port  compatibility  constraints  such  as  hazardous  materials  or  port 
facilities; 

•  staging  and  special  missions  (Marine  amphibious  task  forces,  crane  ships,  etc.); 

•  attrition  and  convoying. 

The  typical  level  of  detail  for  airlift,  motor,  and  rail  provides  for: 

•  individual  aircraft  or  vehicle  tracking  by  fleet  and  trip  (or  flow  analysis  if  desired); 

•  multiple  compartments  and  capacity  measures  with  stow  factors; 

•  matr.hing  of  vehicle/compartment/cargo/airport  compatibility  constraints; 

•  route  selection  based  on  link  distances  and  delays  including  tradeoffs  between  refueling  stops  versus 
critical  leg  payloads  for  aircraft; 

•  travel  time  calculations  including  arrive/depart  or  takeoff/landing  time,  enroute  refueling  stops, 
cruising  speed,  link  delays,  and  link  speed  limits; 

•  load/offload  rates  depending  on  airport  facilities; 

•  throughput  at  facilities  limited  by  arrival/departure  constraints,  cargo  throughput  limits,  maximum  on 
ground  (MOG)  or  parking  constraints,  and  fleet  restrictions; 

•  vehicle  availability  limited  by  utilization  rates  and  fleet  availability. 

Because  the  data  structures  and  level  of  detail  are  defined  in  by  “metadata”  tables  in  the  system,  the  amount  of 
detail  can  be  adjusted  for  each  mode  of  transport  as  required  by  the  study  application. 
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1.7  Map  Graphics 

The  transportation  graphics  module  provides  a  world  map  display  with  origins,  destinations,  seaports,  airports, 
and  transportation  network  nodes/links/channels  as  defined  from  the  database.  The  graphics  provides 
capabilities  to  zoom,  pan,  set  display  options  and  layers,  and  print/plot.  In  addition,  the  scheduling  model  can 
display  vehicle  (ship,  aircraft,  etc.)  location  snapshots  based  on  the  detailed  itineraries  and  the  interpolation  of 
routing  paths.  Currently  the  map  graphics  does  require  the  Maplnfo  commercial  package  as  the  underlying 
graphics  engine,  although  this  is  not  required  to  use  the  rest  of  the  GDAS  system. 


Figure  1-6.  World  Map  Display 

1.8  Current  Status  of  GDAS 

GDAS  is  installed  at  CAA,  USTRANSCOM,  MARAD,  Stanley  Associates,  and  others  for  use  in  ongoing 
studies.  The  current  version  of  GDAS  is  a  stand-alone  system  which  fully  implements  planning,  scheduling, 
and  simulation  for  all  transport  modes  from  origin  to  destination.  Development  of  an  interface  to  the 
USTRANSCOM  AMP  system  has  been  completed  using  JOPES  B8  TPFDD  files.  CAA  is  using  GDAS  for 
transportation  studies  including  Korea  RSOI  (Reception,  Staging,  and  Onward  Integration),  SRA,  and  MRS-05 
(Mobility  Requirements  Study  for  2005).  In  addition,  GDAS  is  currently  being  applied  by  USTRANSCOM,  the 
DOT  Volpe  National  Transportation  Center,  and  Stanley  Associates,  Inc.  for  detailed  modeling  of  the 
Voluntary  Intermodal  Sealift  Agreement  (VISA)  between  DOD  and  commercial  sealift  carriers.  GDAS 
development  continues  in  the  areas  of  handling  of  surprise  events  with  re-scheduling,  data  import,  and  other 
Mihanrftmftnts  GDAS  has  been  verified  by  CAA  in  numerous  test  scenarios  as  well  as  data  from  Desert  Stoim 
and  Restore  Hope  deployments. 
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2.  Overview  of  Model  Algorithms 


2.1  Introduction 

This  Section  provides  a  high-level  overview  of  the  modeling  approach  and  algorithms  developed  for 
GDAS  to  plan,  schedule,  and  simulate  large-scale  multi-modal  transportation  problems  for  DOD 
deployments.  The  primary  objective  of  the  GDAS  model  is  to  provide  a  detailed  analysis  of  transportation 
capabilities  from  origin  to  destination  given  the  movement  requirements,  the  multi-modal  transportation 
network,  the  available  lift  assets,  the  cargo/vehicle  handling  facilities,  and  other  factors.  Alternatively, 
GDAS  can  be  used  to  determine  the  preferred  mix  and  quantity  of  lift  assets  needed  to  meet  delivery 
requirements.  In  order  to  evaluate  the  transportation  system,  GDAS  divides  the  problem  into  planning, 
scheduling,  and  simulation  components  and  implements  algorithms  appropriate  for  each  level. 


2.2  The  DOD  Transportation  Problem 

DOD  deployment  has  unique  characteristics  that  differ  from  commercial  vehicle  routing  and  scheduling 
applications,  namely:  large  magnitude,  high  complexity,  multi-modal  transport,  time-phased  dependencies, 
and  high  time  priorities  versus  cost. 

The  first  characteristic  is  the  magnitude  of  the  problem.  For  large  deployments,  the  number  of  scheduled 
vehicles  can  range  to  the  tens  of  thousands  (ships,  planes,  motor  vehicles,  rail,  etc.)  each  with  multiple 
trips,  and  the  number  of  separately  scheduled  cargos  can  exceed  a  hundred  thousand,  each  with  multiple 
nodes  for  origin,  destination,  intermodal  transfer  points,  and  path  routing.  The  time  frame  generally  spans 
90  to  200  days.  For  recent  GDAS  studies,  the  underlying  transportation  network  includes  about  700  nodes, 
2000  node  facilities,  and  4000  transport  links. 

In  conjunction  with  the  scale  of  the  transportation  is  complexity.  DOD  movements  encompass  all  types  and 
sizes  of  cargo  (heavy  equipment,  passengers,  supplies,  refrigerated  foods  and  medicines,  containers, 
hazardous  materials,  ammunition,  etc.,  ranging  from  personal  effects  to  large  armored  vehicles),  as  well  as 
all  types  of  transportation  facilities,  vehicles,  routing  links,  convoys,  and  resources,  all  with  constraints  on 
matching  availability,  and  throughput  handling.  Many  requirements  may  have  pre-assigned  missions, 
staging  locations,  intermediate  ports,  sequencing  constraints,  timing  priorities,  and  other  deployment 
restrictions. 

A  third  characteristic  of  DOD  transportation  is  the  intrinsic  multi-modal  nature  of  the  deployment.  DOD 
cargos  generally  move  starting  from  CONUS  origins  via  motor,  rail,  and  pipeline  to  POEs  (ports  of 
embarkation),  possibly  with  consolidation  or  assembly  points;  from  POEs  to  PODs  (ports  of  debarkation) 
via  air  or  sea,  possibly  with  intermediate  ports  or  staging  areas;  and  from  PODs  into  die  theater  via  motor, 
rail,  and  air  with  multiple  staging  or  assembly  points.  In  addition,  some  movements  may  start  at 
prepositioned  locations  in  the  theater,  at  sea,  or  at  other  locations  for  earlier  delivery,  again  requiring 
multiple  modes  of  transport. 

A  fourth  characteristic  is  the  critical  nature  of  time-phased  dependencies  between  different  DOD 
movements.  Most  of  the  movement  requirements  are  not  interchangeable  products.  The  DOD  scheduling 
process  must  consider  die  time-phased  coordination  of  different  forces,  die  cumulative  delivery  of 
“balanced”  forces,  the  sequencing  of  combat/support/resupply  movements,  the  retention  of  unit  integrity, 
the  predecessor/successor  relationships  of  multi-modal  movements,  and  the  staging,  packaging,  and 
assembly  of  movements. 

Another  feature  of  DOD  rapid  deployments  which  is  different  from  many  vehicle  scheduling  applications 
is  that  the  movements  are  predominantly  uni-directional  during  the  early  crisis  phases.  The  movements 
may  travel  long  distances  from  CONUS  origins  to  theater  destinations,  and  delivery  vehicles  may  have 
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nearly  empty  return  trips  until  much  later  in  the  deployment.  This  characteristic  can  be  used  to  tune  the 
scheduling  algorithms  for  faster  performance  on  typical  DOD  problems. 

Finally,  DOD  transportation  applications  often  involve  crisis  responses  with  high  time  priorities  and  other 
measures  of  effectiveness,  which  may  take  priority  over  transportation  costs.  Nevertheless,  cost  criteria 
remain  important,  including  tradeoffs  between  air  and  sea,  use  of  fewer  lift  assets  versus  timeliness, 
efficient  routing,  and  full  loading  where  possible. 


2.3  Deployment  Planning  Models 

Because  of  the  importance  of  DOD  mobility,  many  models  have  been  developed  to  analyze  and  simulate 
various  aspects  of  deployment.  Generally,  die  models  can  be  classified  according  to  the  type  of  scheduling 
algorithms  and  the  level  of  detail,  ranging  from  aggregate  linear  programming  with  or  without  time 
periods,  to  cargo  flow  models  using  cargo  quantities,  or  vehicle  flow  models  allocating  vehicle  capacities, 
to  individual  vehicle  scheduling,  down  to  multiple  trip  scheduling  with  route  insertion  and  multiple  pickups 
and  deliveries.  The  various  models  can  also  be  classified  by  usage — long-range  asset  or  budget  planning, 
mid-range  deliberate  planning,  and  short-range  execution  planning  and  re-scheduling.  The  more  detailed 
models  generally  focus  on  a  single  leg  of  the  deployment,  either  CONUS  (origin  to  POE  by  truck,  rail,  and 
organic),  or  strategic  (POE  to  POD  by  air  and  sea),  or  intratheater  (POD  to  destination  or  assembly  area). 
Recently,  USTRANSCOM  has  developed  the  Advanced  Mobility  Platform  (AMP)  to  provide  a  framework 
for  interfacing  several  planning  models  including  MIDAS  (a  strategic  model  from  POE  to  POD  with 
vehicle  flows  for  airlift  and  individual  vehicles  for  sealift),  JFAST  (also  a  strategic  model  with  vehicle 
flows  for  airlift  and  individual  ship  scheduling),  MASS  (a  detailed  airlift  simulation  model  with  some 
scheduling  aspects),  and  ELIST  (an  intratheater  cargo  flow  model).  Although  the  AMP  platform  provides 
an  integrating  framework,  the  individual  models  are  not  fully  integrated  and  have  different  data  structures 
and  inputs. 
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2.4  GDAS  Overview  and  Data  Structures 

GDAS  was  designed  from  the  beginning  to  be  a  highly  detailed  model  for  multi-modal  planning, 
scheduling,  and  simulation  from  origin  to  destination  encompassing  all  modes  of  transport.  Figure  2-1 
provides  a  conceptual  overview  of  the  intermodal  transportation  network.  The  relational  database  structures 
are  designed  to  represent  the  complete  transportation  network  from  origin  to  destination  using  common, 
unified  data  structures  for  all  modes  of  transport,  including  lift  assets,  vehicle  types  and  compartments, 
facilities,  transportation  links,  routes,  movement  requirements  with  staging  and  prepositioning,  multiple 
cargo  dimensions  and  quantity  measures,  and  scheduling  time/cost  objective  functions.  Major  data  inputs 
are  listed  in  Figure  2-2. 

Figure  2-2.  Basic  Transportation  Data  Inputs 

•  Movement  Requirements 

•  Origins,  destinations,  cargo  categories,  quantities,  dimensions,  time  windows  (read  to  load  day,  required 
delivery  day,  earliest  delivery  day) 

•  Transportation  Network 

•  Transport  modes,  nodes,  links,  facilities,  capacities,  constraints 

•  Transport  Vehicles 

•  Vehicles,  capacities,  locations,  availability,  characteristics 

•  Loading  Data 

•  Load/unload  rates,  stow  factors,  cargo/vehicle/facility  compatibility  rules,  cargo  dimension  restrictions 


The  database  and  scheduling  algorithms  are  structured  to  be  completely  data-driven,  from  units  of  measure 
to  transport  modes  and  vehicle  types.  This  permits  the  various  scheduling  algorithms  in  GDAS  to  be 
applied  to  each  mode  at  user-adjustable  levels  of  detail. 


2.5  GDAS  Scheduling  Algorithms 

Because  of  the  large  problem  size,  the  GDAS  strategy  is  to  decompose  the  overall  scheduling  problem  into 
interrelated  subproblems  that  are  solved  iteratively  at  several  levels  using  optimization  and  heuristic 
algorithms  based  on  user  input  constraints,  decision  rules,  and  cost  factors.  At  a  high  level,  decision 
algorithms  examine  tradeoffs  between  multiple  cargos  and  vehicles,  operating  in  phases  at  an  increasing 
level  of  detail,  with  increasingly  firm  decisions  about  the  scheduling.  The  high  level  algorithms  are: 

•  long-range  transportation  planning,  which  assigns  ports,  modes,  planning  fleets,  cargo 
configurations,  and  target  lift  times,  but  not  individual  lift  asset  vehicles  such  as  ships  or  planes 

•  mid-term  cargo/vehicle  scheduling,  which  assigns,  sequences,  and  schedules  (or  re-schedules) 
specific  vehicles,  trips,  stops,  facilities,  and  cargo  loads 

•  event-driven  hourly  simulation,  which  simulates  the  actual  vehicle  loading,  unloading,  facility 
throughput,  facility  vehicle  handling,  queuing,  surprise  events,  etc. 

The  high  level  algorithms  listed  above  utilize  the  solutions  of  other  more  localized  subproblems  which  are 
solved  separately  with  a  narrow  focus.  These  localized  decision-making  sub-algorithms  include: 

•  route  insertion  for  a  candidate  cargo  assignment  and  insertion  into  an  existing  vehicle  route 

•  cargo  loading  for  a  candidate  cargo  onto  multiple  vehicle  compartments 

•  port-to-port  travel  times  with  link  delays,  payload  variations,  speed  limits,  route  constraints,  etc. 
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•  convoying 

•  capacity  event  scheduling  for  facilities  and  nodes  with  cargo  and  vehicle  handling  constraints 

Effective  scheduling  is  a  difficult  problem, 
even  on  a  small  scale.  By  iteratively 
evaluating  the  major  subproblems  and 
efficiently  solving  smaller  subproblems,  the 
GDAS  strategy  is  similar  to  that  of  human 
schedulers.  It  should  be  noted  that  human 
schedulers  perform  quite  well  on  small-scale 
problems,  particularly  in  resolving  special 
situations  and  balancing  competing 
objectives.  GDAS  cannot  globally  optimize 
the  scheduling,  but  rather  attempts  to  match 
the  human  scheduling  ability  on  small 
problems  and  then  applies  this  process 
consistently  on  a  larger  scale. 

GDAS  begins  with  an  initial  long-term 
transportation  planning  from  origin  to 
destination.  After  the  initial  planning,  daily 
iterations  are  performed  consisting  of  mid- 
term  scheduling  and  re-scheduling  using  detailed  route  insertion,  long-term  planning  and  re-planning,  and 
detailed  current-time  event  simulation,  as  shown  in 

Figure  2-3.  The  high  level  algorithms  and  the  localized  subproblem  algorithms  are  summarized  in  the 
paragraphs  below.  Additional  details  are  provided  in  later  sections. 


FOR  EACH  DAY: 

PLAN 

Assign  ports,  fleets,  modes,  cargo 
configurations,  target  lift  times  into  future 

SCHEDULE 

Schedule  cargoes  and  vehicle  itineraries 
forward  into  the  future 

SIMULATE 

Simulate  current  hourly  loading,  facility 
throughput,  queues,  travel  time,  etc. 

UPDATE 

Update  future  plans  and  schedules 
from  simulation,  add  surprise  events 

ITERATE 

Iterate  on  planning,  scheduling, 
simulating,  and  updating 

Figure  2-3.  GDAS  Transportation  Planning  and  Scheduling  Process 

2. 6  High  Level  Algorithms 

2.6.1  Transportation  Planning 

The  transportation  planning  algorithm  determines  the  preferred  transport  modes,  POEs,  PODs,  target  lift 
times,  and  target  delivery  times  for  each  movement  from  origin  to  destination,  without  specifically 
assigning  individual  vehicles.  The  planning  must  account  for  any  mode  exclusions,  required  intermediate 
ports,  and  cargo/vehicle/facility  matching  constraints.  GDAS  uses  a  dynamic  programming  formulation  for 
successive  transportation  planning  of  each  movement  requirement,  with  user-specified  cost  weightings  for 
travel  costs  versus  lateness.  The  dynamic  programming  is  implemented  using  multiple  states  at  each 
network  node  to  represent  all  earliest  arrive  times  for  each  mode  of  transport,  each  planning  fleet,  and  each 
cargo  configuration,  allowing  for  changes  in  mode  or  planning  fleet  at  each  facility.  The  algorithm  is 
considerably  speeded  up  by  calculating  upper  bounds  and  lower  bounds  from  the  current  node  states  to  the 
destination,  enabling  a  branch  and  bound  technique  to  prune  many  of  the  states.  The  dynamic 
programming  algorithm  itself  is  somewhat  “optimal”,  in  that  it  considers  all  transportation  network  nodes, 
all  mode  and  fleet  changes  at  POEs/PODs,  all  cargo  configurations,  all  multi-modal  links,  and  all  routes 
(including  convoy  routes)  for  a  single  requirement.  However,  the  underlying  time  calculations  use 
approximated  delays,  load/unload  times,  and  planning  speeds  by  vehicle  type,  without  actually  assigning 
individual  vehicles,  so  the  state  calculations  are  heuristic.  In  addition,  the  algorithm  evaluates  the 
movement  requirements  successively  with  an  approximate  look-ahead  to  evaluate  interference  effects  on 
later  cargos,  so  that  joint  vehicle  and  facility  tradeoffs  are  evaluated  in  a  moving  time  frame  rather  than  all 
alternatives.  Thus,  the  dynamic  programming  is  used  iteratively  as  a  heuristic  optimization  technique — the 
transportation  planning  generates  plans  with  tentative  ports  and  target  lift  times,  rather  than  detailed 
schedules.  The  actual  assignment  of  vehicles,  trips,  stops,  and  loads  is  determined  later  in  the  scheduling 
algorithm. 
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One  of  the  difficulties  encountered  in  transportation  planning  is  that  the  matching  constraints  between 
cargo  types,  facility  capabilities,  and  individual  transport  vehicles  can  be  very  restrictive.  In  some  cases, 
very  few  vehicles  may  actually  be  feasible  for  a  candidate  lift  assignment,  even  though  the 
cargo/facility/vehicle  types  appear  to  be  compatible.  Examples  include  shallow-draft  seaports  that  exclude 
nearly  every  tanker,  or  airports  with  short  runways.  In  addition,  the  planning  of  such  movement 
requirements  can  strongly  affect  the  availability  of  lift  assets  and  facilities  for  other  movement 
requirements.  As  a  result,  the  transportation  planning  has  since  been  extended  (beyond  its  original  intent) 
to  evaluate  individual  vehicle  and  facility  constraints  and  availabilities,  even  though  the  vehicle 
assignments  are  completely  re-evaluated  later  during  scheduling. 

A  complete  transportation  planning  analysis  is  an  important  first  step  in  GDAS  and  can  consume  half  the 
run  time,  particularly  if  ports  and  transport  modes  are  not  pre-specified.  The  results  represent  a  “cargo 
flow”  view  of  the  entire  plan.  Most  of  the  results,  however,  are  thrown  away  and  only  the  initial  transport 
legs  are  retained  for  subsequent  scheduling,  without  retaining  the  subsequent  mode/port  assignments  or 
successor  legs.  Later,  re-planning  of  successor  cargos  to  their  destinations  is  performed  on  a  daily  basis  as 
the  detailed  scheduling  algorithm  progresses,  again  retaining  only  the  immediate  successor  legs.  This  daily 
re-planning  approach  is  able  to  respond  to  the  latest  scheduling  and  simulation  results,  so  that  the 
preliminary  planning  results  may  be  revised  significantly  during  later  time  frames. 

2.6.2  Cargo/Vehicle  Scheduling 

The  vehicle  scheduling  algorithms  are  invoked  each  day  to  assign  planned  cargos  to  specific  vehicles.  The 
scheduling  is  limited  to  mid-term  cargos  with  target  lift  times  falling  within  a  rolling  time  horizon.  The 
vehicle  scheduling  output  consists  of  updated  vehicle  routes  and  schedules,  including  multiple  trips,  pickup 
and  delivery  stops,  cargo  manifests,  and  compartment  load  quantities.  Currently,  GDAS  has  four 
scheduling  models  at  various  levels  of  detail: 

•  a  quick  travel  time  algorithm,  which  matches  vehicle  characteristics  with  cargos  and  facilities  and 
estimate  travel  times  with  unconstrained  vehicle  availability 

•  a  vehicle  flow  model  which  allocates  vehicle  hours  based  on  round  trip  time  calculations 
(comparable  to  the  MIDAS  and  JFAST  airlift  models) 

•  a  more  detailed  pickup/delivery  scheduling  algorithm  which  performs  cost-based  assignments  of 
cargos  to  successive  trips  allowing  multiple  cargos  per  trip  and  tracking  the  discrete  location  of 
each  vehicle  on  each  trip,  but  which  schedules  only  one  POE  stop  and  one  POD  stop  per  trip  (this 
is  suitable  when  POE/POD  channels  have  total  movement  quantities  much  larger  than  individual 
vehicle  capacities,  such  as  airlift  or  truck,  for  which  only  the  last  few  vehicle  trips  are  partially 
loaded) 

•  the  most  detailed  multi-port  algorithm,  which  utilizes  cost-based  route  insertion  heuristics  to 
assign  multiple  pickup  and  delivery,  stops  on  each  vehicle  trip. 

In  the  model,  any  of  the  scheduling  algorithms  can  be  applied  to  any  mode  of  transport  as  desired  by  the 
user.  In  general,  the  first  two  flow  algorithms  tend  to  over-estimate  lift  capability  if  few  vehicles  or  large 
vehicles  are  available,  since  vehicle  flows  are  split  unrealistically  among  different  routes  and  the  discrete 
trip  travel  times  and  return  times  are  not  accurately  calculated.  (This  is  the  difficulty  with  linear 
programming  and  network  flow  techniques  used  to  model  aggregate  ports,  time  periods,  and  large  discrete 
vehicles  such  as  ships — the  discrete  scheduling  and  routing  difficulties  are  aggregated  away.).  For  large 
individual  vehicles  such  as  ships,  it  is  recommended  that  the  last  two  discrete  scheduling  and  routing 
algorithms  be  used. 

One  issue  for  computer  algorithms  is  how  to  define  “costs”  or  penalties.  In  GDAS,  penalties  are  used  to 
evaluate  the  basic  tradeoff  between  vehicle  usage  and  cargo  delivery  timeliness.  The  penalty  factors  can  be 
adjusted  in  the  database  to  account  for  vehicle  travel  times  ($/day),  cargo  lateness  ($/ton-day),  initial 
vehicle  usage  ($/use),  port  visits  ($/visit),  etc.  as  shown  previously  in  Section  5.7.5.  Some  of  the  penalty 
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elements  are  calibrated  from  test  runs,  since  factors  such  as  lateness  cost  represent  policy  decisions  that  are 
not  easily  quantified. 

In  vehicle  scheduling  applications,  it  is  very  easy  to  develop  solution  algorithms  that  run  for  unreasonable 
amounts  of  time  even  on  relatively  small  problems.  Human  schedulers  are  quickly  able  to  screen  out  many 
impractical  transportation  alternatives  because  they  know  intuitively  that  the  associated  schedules  are  either 
infeasible  or  too  costly.  Similarly,  they  can  focus  special  attention  on  difficult  constraints  such  as  shallow 
draft,  based  on  experience  in  a  particular  port.  The  ability  to  screen  out  infeasible  solutions  early  and  focus 
more  extensive  tradeoff  calculations  for  promising  solutions  is  an  important  technique  in  reducing  run  time 
for  GDAS  algorithms  as  well. 

One  basic  technique  in  GDAS  is  to  precompute  cargo/vehicle/facility  matching  arrays,  which  can  be 
quickly  checked  for  screening  out  infeasible  combinations.  In  addition,  for  cost-based  screening,  a 
mathematical  technique  known  as  branch  and  bound  is  implemented  which  uses  upper  and  lower  bounds  to 
eliminate  many  alternatives.  If  an  upper  bound  on  the  best  cost  is  already  known  based  on  some  feasible 
solution  (usually  the  best  candidate  solution  found  so  far),  then  any  time  a  new  partial  solution  exceeds  that 
known  cost,  the  new  solution  can  be  rejected  immediately  as  unacceptable,  including  all  derived  solutions. 
This  upper  bound  screening  can  be  further  accelerated  using  lower  bounds.  If  tight  lower  bounds  on  the 
potential  cost  for  a  solution  can  be  determined  quickly  (typically  using  direct  distance  calculations  and 
travel  times  in  GDAS),  then  a  partial  solution  can  be  rejected  early  if  its  partial  cost  plus  the  remaining 
lower  bound  exceed  the  known  upper  bound.  An  additional  strategy  is  to  permit  the  user  to  set  criteria  for 
“good  enough”  thresholds,  which  can  lead  to  immediate  assignments  with  much  shorter  search  times. 

These  strategies  are  used  throughout  all  GDAS  algorithms  and  significantly  reduce  the  run  time. 

Basically  the  vehicle  scheduling  algorithm  evaluates  a  large  number  of  candidate  cargo/vehicle 
assignments  and  selects  those  that  are  most  promising  for  scheduling.  Because  of  the  large  problem  size,  it 
is  impossible  to  evaluate  all  assignments  and  combinations  of  assignments.  Large  scale  integer 
programming  optimization  strategies  such  as  Lagrangean  relaxation  were  not  attempted  for  this  problem 
size,  which  has  thousands  of  vehicles  and  perhaps  a  hundred  thousand  stops.  Specialized  greedy  algorithms 
using  route  insertion  techniques  have  been  widely  implemented  in  commercial  vehicle  scheduling  systems 
and  have  been  adopted  for  GDAS  in  the  detailed  scheduling  algorithms.  The  GDAS  strategy  is  somewhat 
different  from  other  search  strategies  in  that  it  alternates  between  a  “greedy  cargo”  perspective  and  a 
“greedy  vehicle”  perspective,  reflecting  the  basic  conflict  between  cargo  timeliness  and  efficient  vehicle 
usage. 

In  the  greedy  cargo  perspective,  the  next  planned  cargo,  sorted  by  target  lift  time  and  priority  within  a 
rolling  time  horizon,  is  evaluated  to  determine  the  “marginal  cost”  of  assigning  it  to  all  possible  matching 
vehicles.  This  costing  uses  the  route  insertion  algorithm  discussed  below,  in  which  a  candidate  vehicle  is 
evaluated  including  its  previously  assigned  trips,  stops,  and  cargos  if  any.  In  evaluating  the  candidate 
assignment  cost,  user-specified  penalties  are  incurred  for  incremental  vehicle  time,  cargo  lateness, 
compartment  stowage,  port  visits,  new  vehicle  usage  versus  re-use,  as  well  as  the  implied  lateness  effects 
on  other  cargos  later  in  the  schedule  (this  latter  requires  difficult  iterative  calculations  but  the  implied 
lateness  information  is  very  important).  The  least-cost  candidate  vehicle  assignment  is  then  selected  for  the 
cargo,  all  schedules  are  updated,  and  successor  cargos  are  re-planned. 

If  the  assigned  vehicle  trip  is  not  fully  loaded  by  a  cargo,  then  the  scheduling  algorithm  switches  to  a 
greedy  vehicle  perspective.  This  perspective  looks  at  other  cargos  in  the  same  POE/POD  channel  and  time 
horizon,  costs  out  the  candidate  assignments,  and  selects  cargo  that  can  be  added  to  the  vehicle  with 
reasonable  penalty  costs  based  on  detailed  route  insertion.  This  switching  to  a  vehicle  perspective  has 
proven  to  be  very  effective  because  the  cargo  algorithm  alone  tends  to  be  too  myopic  about  efficiently 
using  the  lift  assets.  The  greedy  vehicle  approach  is  also  important  for  run  time  efficiency,  since  it 
effectively  aggregates  movement  channels  “on  the  fly”  and  focuses  on  a  small  subset  of  promising 
candidate  assignments,  particularly  for  loading  many  small  movement  requirements  on  a  large  ship. 
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It  should  be  noted  that  updating  the  vehicle  schedules  is  more  complex  than  might  be  expected  because  of 
the  multi-modal  transportation  network.  For  example,  if  a  single  cargo  is  added  to  a  previously  assigned 
intertheater  ship  schedule,  this  can  cause  delays  to  all  other  cargos  on  board  the  same  ship  trip.  These 
delays  then  propagate  to  the  offloading  of  the  cargos  at  later  PODs,  which  again  delays  the  onloading  of 
successor  cargos  at  POEs  for  the  next  transport  leg  (e.g.,  airlift  in  the  theater).  This  can  lead  to  later  delays 
that  must  be  recursively  propagated  throughout  all  schedules  into  the  future.  It  is  important  to  accurately 
update  all  of  the  future  schedules  in  order  to  evaluate  the  potential  side  effects  of  a  candidate  cargo/vehicle 
assignment. 

2.6.3  Simulation 

The  event-driven  hourly  simulation  algorithm  is  executed  each  day  to  accurately  calculate  the  arrival, 
departure,  loading,  unloading,  and  queuing  events  at  each  facility.  The  detailed  facility  throughput 
calculations  and  vehicle  queuing  delays  can  cause  the  simulated  event  times  to  vary  from  the  original 
scheduled  times.  In  addition,  unforeseen  surprise  events  can  be  injected  and,  as  a  future  addition,  stochastic 
sampling  can  be  applied  to  the  event  times.  The  simulation  algorithms  use  a  standard  approach  that 
maintains  a  sorted  heap  (priority  queue)  containing  the  next  incomplete  simulation  event  for  each  vehicle 
trip.  For  efficiency,  only  one  future  event  is  stored  on  the  heap  for  each  trip,  since  successor  events  on  a 
single  trip  cannot  occur  simultaneously \  and  later  events  are  added  as  the  predecessor  events  are  completed. 
This  also  reduces  the  need  to  update  future  events  stored  on  the  heap.  During  simulation,  scheduled  events 
are  pulled  from  the  heap  and  executed,  with  further  simulation  forward  into  time  where  no  interference  can 
occur.  Then  the  final  simulated  times  are  stored,  the  next  event  is  put  on  the  heap,  any  delays  are 
propagated  forward,  and  all  future  schedules  are  updated.  Simulation  is  suspended  at  the  end  of  each  day, 
which  provides  a  chance  for  additional  planning  and  scheduling  the  next  day  prior  to  additional  simulation. 


2. 7  Localized  Subproblem  Algorithms 

2.7.1  Route  Insertion 

Route  insertion  is  an  important  sub-algorithm  used  in  scheduling  to  evaluate  candidate  cargo/vehicle 
assignments.  The  basic  inputs  for  route  insertion  consist  of  a  new  candidate  cargo  to  be  assigned  (with  its 
planned  POE,  POD,  and  target  lift  times),  plus  a  candidate  vehicle  for  assignment  (which  may  already  have 
an  itinerary  consisting  of  trips,  stops,  and  previously  assigned  cargos).  The  objective  of  the  route  insertion 
is  to  find  the  least  cost  change  in  the  existing  vehicle  itinerary  so  as  to  pickup  and  deliver  the  new 
rapdidaf*  cargo.  Run  time  is  an  important  consideration  since  the  vehicle  scheduling  calls  route  insertion 
many  times  in  costing  out  candidate  assignments.  An  early  route  insertion  algorithm  using  dynamic 
programming  with  branch  and  bound  was  rejected  because  of  run  time. 

The  current  route  insertion  in  GDAS  uses  a  search  heuristic  to  insert  the  POE  and  POD  while  iterating 
down  the  previously  scheduled  vehicle  stops.  The  iteration  begins  at  an  earliest  feasible  insertion  point, 
which  is  determined  by  the  remaining  capacity  on  each  trip  as  well  as  the  current  simulation  status  (cargos 
cannot  be  inserted  before  historical  stops  which  have  already  been  simulated).  In  moving  down  the  vehicle 
itinerary,  the  candidate  POE  is  inserted  if  it  can  be  processed  prior  to  the  next  stop  in  the  trip,  subject  to 
various  other  insertion  rules.  Then  the  POD  is  inserted  within  the  same  trip  with  similar  insertion  rules.  The 
incremental  insertion  cost  is  accumulated  down  the  route,  including  delays  for  other  cargos  scheduled  on 
the  same  vehicle,  possibly  continuing  to  later  trips.  If  the  load  quantity  is  too  small  or  the  insertion  cost 
gets  too  high  relative  to  the  current  upper  bounds,  the  POE  insertion  may  need  to  be  re-started  at  a  later 
point  in  the  route,  leading  to  a  second  or  third  pass  on  POE/POD  insertion.  Wherever  possible,  bounds  are 
used  to  truncate  the  search  early.  Although  many  variations  of  route  insertion  have  been  discussed  in  the 
literature,  the  GDAS  versions  are  particularly  efficient  for  the  situation  in  which  routes  tend  to  be 
unidirectional  with  POEs  separated  from  PODs. 
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2.7.2  Port-to-Port  Travel  Times 

The  port-to-port  travel  time  algorithm  determines  the  “best”  path  for  a  vehicle  from  one  port  facility  to 
another  for  a  given  route  type,  based  on  maximizing  the  overall  payload  throughput  per  unit  time.  The  path 
algorithm  takes  into  account  the  travel  nodes  and  links,  the  allowable  link  constraints,  link  delays,  refueling 
requirements  at  allowable  facilities,  and  (for  airlift)  tradeoffs  between  allowable  payload,  critical  leg 
distance  (the  longest  leg  without  refueling),  and  total  travel  time  including  landings  and  takeoffs.  An 
additional  refueling  complication  occurs  when  refueling  is  not  permitted  at  the  POD,  in  which  case  the  path 
algorithm  must  find  a  recovery  base  for  refueling.  After  each  path  optimization,  the  cumulative  path  data  is 
computed  and  stored  for  later  re-use,  including  travel  time,  delays,  attrition  probabilities,  routing 
restrictions,  and  convoy  data  if  relevant.  This  incremental  routing  and  storage  is  necessary  because  pre¬ 
calculation  of  a  complete  distance  matrix  encompassing  all  different  route  types  is  impractical,  with 
literally  millions  of  records,  since  different  vehicle  types  have  different  routing  constraints  and  refueling 
tradeoffs.  Thus,  the  path  algorithm  builds  a  computed  distance  matrix  incrementally  as  needed  during  the 
scheduling  process.  The  path  algorithm  is  called  frequently  during  route  insertion  and  scheduling,  so  it  is  a 
major  run  time  concern  even  when  the  cumulative  port-to-port  results  are  stored  and  re-used  once 
calculated.  Initially,  a  fast  path  algorithm  was  developed  using  shortest  path  with  directional  lower 
bounding,  but  this  did  not  adequately  address  refueling  restrictions  or  payload  tradeoffs.  A  dynamic 
programming  algorithm  was  later  developed,  with  multiple  states  at  each  node  representing  the  non- 
dominated  arrive  time  and  critical  leg,  and  with  upper/lower  bounds  for  branch  and  bound,  but  this  method 
was  too  slow,  even  when  initialized  with  shortest  paths  as  upper  bounds.  Currently,  GDAS  uses  multiple 
shortest  path  calls  with  iterations  on  critical  leg  distance  and  refuel  weighting;  a  unimodal  two-dimensional 
search  is  used  to  select  the  best  route  that  maximizes  the  payload  per  unit  time  for  each  route  type  and  each 
port-to-port  combination. 

2.7.3  Cargo  Loading 

The  cargo  loading  subproblem  is  also  solved  many  times  during  the  scheduling  algorithm  to  calculate  how 
much  cargo  can  be  loaded  into  multiple  compartments  for  a  candidate  lift  assignment.  The  data  structures 
are  designed  to  handle  all  modes  of  transport  within  a  common  framework.  The  loading  model  is  also 
designed  to  permit  multiple  capacity  constraints  based  on  actual  cargo  densities,  so  that  “averaged” 
payloads  and  stow  factors  need  not  be  calibrated  for  a  specific  theater  or  strategic  leg.  Airlift  payloads,  in 
particular,  can  change  significantly  for  different  cargo  densities  and  for  delivery  to  Korea  versus  the 
Caribbean,  for  example.  For  loading  purposes,  each  vehicle  can  have  multiple  compartments,  each  with 
multiple  capacities  expressed  in  different  units  of  measure.  For  example,  a  fast  sealift  ship  may  be 
represented  with  three  or  four  compartments  each  with  stowable  capacity  limits  on  both  volume  and  area. 
Aircraft  may  have  cargo-only  compartments,  passenger-only  compartments,  and/or  shared  compartments, 
each  limited  by  volume,  area,  and  number  of  passengers.  In  addition,  each  vehicle  has  a  total  payload 
capacity  over  all  compartments,  and  this  payload  may  depend  on  the  critical  leg  of  the  vehicle  route.  For 
different  compartments,  the  different  cargo  types  have  separate  constraints  and  penalties  for  loading,  as 
well  as  separate  stow  factors  that  vary  by  compartment  type  and  capacity  units  of  measure. 

The  loading  model  itself  uses  a  least  stow  penalty  heuristic  for  loading  a  given  cargo  on  a  vehicle.  For  each 
cargo,  the  allowable  compartments  are  pre-sorted  in  order  of  preference;  the  multiple  capacity  constraints 
are  evaluated  for  each  compartment  allowing  for  other  cargos  which  may  be  on  board;  and  the  allowable 
load  quantities  are  determined  based  on  the  most  constraining  capacity  measure.  Thus,  the  densities  of  the 
onboard  cargos  determine  which  capacity  measure  is  the  most  constraining  for  a  given  compartment,  in 
addition  to  the  payload  limits  based  on  critical  leg  tradeoffs — the  particular  load  may  weight  out,  cube  out, 
or  square  out.  The  loading  model  returns  the  amount  of  cargo  that  can  be  loaded  in  each  compartment  as 
well  as  a  stowage  penalty  that  is  used  in  the  objective  function  for  scheduling. 
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2.7.4  Capacity  Event  Scheduling 

In  addition  to  assigning  cargo  to  vehicles  for  transportation,  the  scheduling  algorithm  must  reserve  capacity 
at  facilities  and  nodes  into  the  future  to  account  for  bottleneck  delays.  The  capacity  reservation  process  is 
performed  using  an  event-based  algorithm.  Each  facility  and  measure  with  limited  capacity  is  modeled 
using  a  forward  linked  list  of  capacity  change  events.  At  each  event,  the  capacity  (for  one  or  more 
measures)  is  either  decreased  or  increased  by  a  specific  amount.  When  a  cargo  begins  loading,  there  is  an 
associated  event  that  reduces  available  capacity;  when  a  cargo  completes  loading,  there  is  an  associated 
event  that  increases  available  capacity.  Once  facility  capacity  is  saturated,  a  cargo  may  offload  at  a  partial 
rate  or  may  be  blocked  entirely  until  resources  are  freed  up  at  a  later  event,  causing  delays.  Each  change  in 
load  rate  has  a  capacity  event.  When  the  events  are  posted,  they  reserve  space  for  cargo  loading  and 
unloading,  or  free  up  space,  or  change  a  load  rate.  Subsequent  schedule  evaluations  can  then  account  for 
the  delays  at  constrained  facilities,  and  even  route  around  the  bottlenecks.  The  capacity  event  algorithm  is 
used  both  for  transportation  planning  and  for  scheduling,  to  model  the  node  and  facility  capacity  utilization 
into  the  future.  In  addition,  a  similar  algorithm  is  used  to  reserve  capacity  for  each  planning  fleet  during  the 
initial  transportation  planning,  prior  to  assigning  individual  vehicles  in  scheduling. 


GDAS  Algorithm  Description 


2-9 


Database  Design  Guidelines 


3.  Database  Design  Guidelines 


3.1  Database 

In  GDAS,  a  scenario  database  represents  a  collection  of  related  information  describing  a  single  scenario  for 
transportation  analysis.  Each  scenario  database  is  stored  in  a  single  subdirectory  under  GDAS  and  consists 
of  a  complete  set  of  tables  and  data  that  define  the  scenario  characteristics  for  the  GDAS  model. 


3.2  Tables 

All  data  for  GDAS  is  stored  in  tables  containing  rows  and  columns.  Each  table  stores  information  about 
multiple  objects  or  entities  that  have  similar  properties  or  attributes.  Different  kinds  of  objects  are  stored  in 
different  tables,  e.g.  a  cargo  record  is  stored  in  die  CARGO  table  and  a  vehicle  record  is  stored  in  die 
VEHICLE  table.  Some  tables  store  “conceptual”  rather  than  physical  objects,  such  as  a  Vehicle  Type 
which  is  listed  in  the  VehType  table. 


3.3  Rows  and  Columns 

Within  a  table,  each  row,  or  record,  stores  all  the  data  about  a  single  object  and  basically  represents  that 
object.  Each  column  stores  one  kind  of  data  value,  or  field  value,  for  the  objects.  The  terms  row,  record, 
object,  or  entity  are  used  interchangeably.  The  terms  column,  field,  attribute,  or  property  are  also  used 
interchangeably.  The  row/column  structure  of  tables  is  directiy  apparent  when  the  initial  table  view  is 
displayed,  as  shown  in  Figure  3-1  for  the  VehFleet  table.  In  the  figure,  the  left-most  column  is  an  internal 
record  number  for  display  purposes  only;  it  is  not  editable  data  and  is  transient,  since  it  changes  depending 
on  the  sort  order  of  the  table.  Three  of  the  data  columns  are  displayed,  the  Vehicle  Type,  the  Vehicle 
Identifier,  and  the  Vehicle  Fleet.  A  fourth  column.  Number  of  Vehicles,  begins  on  the  right  with  “Nu”. 
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Figure  3-1.  Tabular  View  of  the  VehFleet  table 


GDAS  Algorithm  Description 


3-1 


Database  Design  Guidelines 


3.4  Domains 

Each  column  or  field  has  an  allowable  set  of  values  called  a  domain.  Some  domains  are  text,  such  as  names 
or  identifiers,  and  other  domains  are  numeric.  In  Figure  3-1,  the  Vehicle  Fleet  column  is  text,  and  can  store 
any  user-defined  alpha-numeric  characters  up  to  15  characters.  The  Vehicle  Type  column  also  has  a  15 
character  domain,  except  that  for  consistency  the  allowable  values  in  V ehFleet  are  restricted  to  those  listed 
in  the  VehType  lookup  table  (more  on  this  later).  The  Number  of  Vehicles  column  has  a  numeric  domain, 
consisting  of  non-negative  integers  from  0  to  32,767  (this  is  a  “short”  or  two  byte  integer).  Other  domains 
used  in  GDAS  include  latitude  and  longitude,  which  are  partially  numeric  and  partially  text  with  a 
particular  format.  All  of  the  domains  are  defined  in  the  Data  Dictionary,  and  all  data  entries  are  checked 
immediately  for  consistency  with  the  domain. 

3.5  Key  Fields 

One  of  the  most  important  operations  in  a  database  is  to  identify  a  particular  record  in  a  table,  since  each 
record  represents  a  single  object.  Since  records  can  be  added  or  deleted  or  sorted,  the  internal  record 
number  is  not  a  stable  identifier.  Instead,  data  values  are  used  to  identify  objects.  The  data  in  a  record  is 
specific  to  a  single  object  and  represents  that  object;  every  record  has  something  different  about  it,  or  else  it 
basically  becomes  indistinguishable  as  a  separate  object. 

The  minimal  set  of  data  that  uniquely  identifies  a  record  in  a  table  is  called  the  “key”  field(s).  A  record  is 
uniquely  identified  by  the  values  of  its  “key”  fields.  Stated  another  way,  no  two  records  can  have  the  same 
values  in  their  key  fields.  In  fact,  attempting  to  insert  a  new  record  having  the  same  key  values  as  another 
record  yields  a  warning  in  GDAS,  since  it  may  overwrite  existing  data  about  the  matching  record.  The  key 
field  values  uniquely  identify  or  “name”  the  object  or  record,  which  is  then  further  described  by  the  non¬ 
key  field  values  or  attributes.  Key  fields  can  be  text  identifiers  (similar  to  names)  or  numeric  identifiers 
(often  used  for  output  tables  in  GDAS,  such  as  the  TRIP  table).  In  changing  a  non-key  field,  you  are 
describing  the  data  about  an  object;  in  changing  a  key  field,  you  are  changing  the  name  or  identifier  that 
represents  an  object.  To  insert  a  new  object,  you  must  identify  it  uniquely  with  the  key  field  values. 

In  the  VehFleet  example,  the  key  fields  are  the  first  three  fields,  so  that  any  VehFleet  record  is  uniquely 
identified  by  its  Vehicle  Type,  Vehicle  Identifier,  and  Vehicle  Fleet  values.  Two  records  can  have  the  same 
Number  of  Vehicles  (a  non-key  attribute),  but  they  must  be  different  in  at  least  one  key  field  value. 

Because  of  the  importance  of  key  fields,  GDAS  always  places  the  intrinsic  key  fields  first  in  a  table.  In 
addition,  the  table  is  sorted  by  the  key  fields  by  default.  In  a  form  view,  the  key  fields  have  a  background 
of  dark  blue  (versus  light  blue  or  cyan  for  non-key  fields)  to  emphasize  the  key  field  importance  in 
identifying  the  record. 

3.6  Forms 

Forms  in  GDAS  allow  you  to  view  all  of  die  data  about  a  single  record  or  object.  Thus,  the  data  displayed 
in  a  form  view  all  pertain  to  the  object  uniquely  identified  by  the  dark  blue  key  field  values  for  the  current 
record.  Form  views  are  especially  useful  for  data  entry,  since  generally  it  is  easier  to  work  with  one  object 
at  a  time.  The  form  view  for  the  Vehicle  Fleet  table  is  shown  in  Figure  3-2.  The  basic  fields  for  the 
VehFleet  record  are  shown  in  the  upper  left  area  of  the  form  for  a  Vehicle  Type  of  C-141,  Vehicle 
Identifier  of  C-141  (in  this  case,  only  one  kind  of  C-141  vehicle  is  defined,  so  they  have  the  same  name), 
and  a  Vehicle  Fleet  of  “McChord  AFB”  (this  fleet  name  matches  the  Start  Node  in  this  case,  but  need  not 
in  all  cases,  since  die  same  kind  of  vehicles  can  start  out  at  the  same  node  at  different  times). 


GDAS  Algorithm  Description 


3-2 


Database  Design  Guidelines 


[Esc) -Quit  [Ins] -Add 


Vehicle  Type: 
Veh  Id:  C-141 
Vehicle  Fleet: 
Number  Vehicles : 
Start  Node: 
Start  Facility: 
Special  Mission: 
New  Veh  Penalty: 
Day  Available: 
Day  Returned: 
Call  Sign: 
NISC  Number: 
- —  Node 


C-141 

McChord 

50 

McChord 

Airport 

1 

1 


Delete  [F2]-Post  [F7] -Table  Image  More  Help  ^ 

i .  Vehfleet  Form  View  " 

<  -  Vehicle  Data 


AFB 


AFB 


Node  Type: 
Theater: 
Node  Lat: 
Node  Long: 
Geoloc : 
Attr  Prob  %: 
Node  Gone?: 


Airport 
CONUS 
47  07. ON 
122  28. OW 
PQWY 

1 


-  77  of  348  - 1 

Vehicle  Fleet  I  [Fl0]-Menu 


Cruise  Speed: 
Fac  Len  Req: 
Fac  Dim  Req: 


425  Max  Payld:  25  ■ 

5000  Width  Req:  9C 

Capab  Req: 


-  Vehicle  Type  - 

Route  Type: C-141 
Utilization  Rate  %:  39 

Arrive/Depart  Time:  1 

Standard  Size  %:  110 

Time  Penalty:  20 

Greedy  Veh  Level:  1 

Link  Attrit  Scale  %:  100 

Node  Attrit  Scale  %:  100 

Attrit  Partial  %: 

Repair  Days: 

Replace  Days: 
-  Mission 


Begin:  End: 

Offload  Delay  Hrs: 


[|<3  [«]  [<H  [->]  [»1  [>ll  [FI]  [' 


'3  [wj 

View 


Figure  3-2.  Form  View  of  the  VehFleet  table 


Form  views  can  also  display  related  information  from  other  tables.  The  convention  in  GDAS  forms  is  that 
data  from  other  tables  are  displayed  in  separately  boxed  areas  on  the  form,  with  a  single  line  border  for 
singly  related  records  (used  for  lookup  tables  such  as  VehType  in  the  figure),  and  a  double  line  border  for 
multiple  related  records  (a  1  to  many  relationship,  not  shown  in  the  VehFleet  example).  The  data  in  related 
tables  on  a  form  still  pertain  to  the  key  fields  of  the  base  table.  For  example,  the  Node  area  on  the  VehFleet 
form  gives  the  Latitude  and  Longitude  of  the  Start  Node  (McChord  AFB  in  this  case),  the  Vehicle  Data 
area  specifies  the  Cruise  Speed  of  the  Vehicle  Type  and  Identifier  (C-141  in  the  case),  and  the  Vehicle 
Type  data  specifies  the  Arrive/Depart  Time  (or  landing/takeoff  time)  for  the  referenced  Vehicle  Type  (C- 
141  in  this  case).  The  multi-table  form  view  makes  it  convenient  to  view  and  edit  related  data  in  other 
tables  while  editing  the  VehFleet  records. 


3.7  Lookups,  Relationships,  and  Foreign  Keys 

As  seen  in  the  form  view,  the  data  stored  in  a  table  is  often  related  to  other  tables.  For  example,  the  Start 
Node  and  Start  Facility  values  for  a  VehFleet  record  must  reference  a  valid  Node  and  Facility  listed  in  the 
Facility  table  These  “lookup”  or  cross  reference  fields  ensure  that  the  data  is  consistent  between  different 
tables.  In  relational  database  theory,  such  lookup  fields  from  a  “child”  table  to  a  “parent”  table  are  known 
as  foreign  keys  in  a  one-to-many  relationship.  The  relationship  is  termed  one-to-many  since  each  VehFleet 
record,  for  example,  has  exactly  one  matching  Facility  record  for  its  Start  Node  and  Start  Facility,  whereas 
a  Facility  record  can  be  referenced  multiple  times  by  different  vehicle  fleet  records.  The  lookup  table 
Facility  is  known  as  the  parent  table,  and  the  referencing  table  with  foreign  keys  such  as  VehFleet  is  known 
as  the  child  table.  The  lookup  relationship  can  be  a  single  key  field,  as  in  die  Special  Mission  field  in  the 
figure,  or  multiple  key  fields,  as  in  the  Start  Node  and  Start  Facility.  The  uniqueness  of  key  fields  is  what 
ipalfeg  it  possible  to  define  relationships  in  terms  of  foreign  key  field  references. 

In  GDAS,  die  lookup  tables  serve  as  a  pick  list  accessed  using  the  FI  key,  so  that  it  is  easy  to  select  the 
matching  parent  record  and  store  it  in  the  child  table  being  edited.  In  addition,  all  key  field  relationships  are 
checked  whenever  record  edits  are  posted. 

In  order  for  the  key  field  references  to  make  sense,  you  need  to  work  in  a  “top  down”  direction  for  new 
records.  This  means  that  parent  records  need  to  be  created  before  referencing  their  key  fields  in  a  child 
record.  For  example,  node  records  need  to  be  created  in  the  Node  table,  and  then  facility  records  added  for 
that  node  in  the  Facility  table,  before  a  vehicle  fleet  record  in  the  VehFleet  can  be  assigned  to  start  out  at 
the  new  nodes  and  facilities. 
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3.8  Data  Dictionary 

The  Data  Dictionary  provides  a  complete  definition  of  the  tables,  fields,  key  fields,  domains,  lookups,  units 
of  measures,  and  descriptions  in  the  GDAS  system.  The  online  Help/Data  menu  provides  immediate 
access  to  the  Data  Dictionary  while  you  are  editing  tables.  One  of  the  most  valuable  uses  of  the  Data 
Dictionary  is  to  understand  the  relationships  between  tables  so  that  you  can  work  in  a  consistent,  top-down 
fashion  in  defining  new  records  in  GDAS  (e.g.,  for  adding  a  new  Transport  Mode). 

The  complete  Data  Dictionary  is  provided  later.  An  extract  for  the  VehFleet  table  is  shown  in  Figure  3-3. 
The  first  boxed  area  lists  lists  the  8  character  table  name  VehFleet,  its  long  table  name  “Vehicle  Fleet”,  and 
a  description  of  the  table.  Below  the  table  information  is  a  list  of  fields  belonging  to  the  table  along  with 
field  definitions.  In  the  field  list,  the  first  column  repeats  the  table  name,  VehFleet.  The  second  column  lists 
the  field  number  and  field  name,  e.g.  the  first  field  is  Vehicle  Type. 


VEHFLEET  Vehicle  Fleet 

Lists  the  availability  of  vehicles  by  starting  location,  starting  time, 
and  number  of  vehicles 

Domain/ 


Table 

i 

Field  Name 

Lookup 

Key? 

In/Out  Unit  Meas  Description 

_ l _ 1 _ - — 

VEHFLEET 

1 

Vehicle  Type 

VEHDATA 

Y 

In 

Vehicle  type 

VEHFLEET 

2 

Vehicle  Identifier 

VEHDATA 

Y 

In 

Vehicle  identifier  for  this  start  location 

VEHFLEET 

3 

Vehicle  Fleet 

A15 

Y 

In 

Fleet  identifier  for  this  start  location 

VEHFLEET 

4 

Number  of  Vehicles 

Short>=0 

In 

Number  of  vehicles  in  the  fleet  for  this 
vehicle  type 

VEHFLEET 

5 

Start  Node 

FACILITY 

In 

Home  base  node  for  this  fleet  and  vehicle 
type  (a  vehicle  returns  to  its  home  base 
if  not  otherwise  assigned) 

VEHFLEET 

6 

Start  Facility 

FACILITY 

In 

Home  base  facility  for  this  fleet  and 
vehicle  type  (a  vehicle  returns  to  its  home 
base  if  not  otherwise  assigned) 

VEHFLEET 

7 

Start  Day  Available 

DayToHr 

In 

day 

(hr) 

Day  that  this  fleet  and  vehicle  type  are 
first  available 

VEHFLEET 

8 

Last  Day  Returned 

DayToHr 

In 

day 

(hr) 

Day  that  this  fleet  and  vehicle  type  are 
returned  to  base  with  no  more  use  (blank 

or  0  is  treated  as  available  to  the  end) 

VEHFLEET 

9 

Special  Mission 

MISSION 

In 

Special  mission  which  restricts  this  fleet 
to  matching  special  mission  movement 
requirements  for  a  designated  time  period 

VEHFLEET 

10 

New  Vehicle  Penalty 

Short>=0 

In 

$/new  veh 

Penalty  for  the  first  use  of  a  new  vehicle 

of  this  type  and  fleet 

VEHFLEET 

11 

Call  Sign 

A4 

In 

International  call  sign  of  the  vehicle  or 
ship  or  fleet 

VEHFLEET 

12 

NISC  Number 

A5 

In 

Naval  Intelligence  Security  Code  number  of 
the  vehicle  or  ship  fleet 

Figure  3-3.  Data  Dictionary  Extract  for  the  VehFleet  Table 

The  third  column  is  labeled  as  “Domain/Lookup”,  meaning  that  it  displays  either  a  domain  or  a  lookup 
table.  If  an  upper-case  lookup  table  name  is  shown,  then  the  field  has  a  lookup,  and  the  domain  is  inherited 
from  the  parent  table.  For  example,  die  first  two  fields  have  a  joint  lookup  into  VehData,  which  means  that 
all  Vehicle  Type  and  Vehicle  Identifier  combinations  in  the  VehFleet  must  match  the  parent  values  in  the 
VehData  lookup  table,  and  they  are  text  strings  or  names.  Similarly,  the  Start  Node  and  Start  Facility  fields 
have  a  joint  lookup  to  the  Facility  table.  This  means  that  you  must  create  a  matching  node  and  facility  in 
die  Facility  parent  table  before  you  can  assign  vehicles  to  start  at  that  facility  in  the  VehFleet  table.  The 
two  “foreign  key  fields”.  Start  Node  and  Start  Facility  in  the  VehFleet  child  table,  must  match  the  parent 
key  fields.  Facility  Node  and  Facility  Name,  for  a  parent  record  in  the  Facility  table.  The  lookup  values  are 
always  the  key  fields  of  the  parent  table. 


If  the  third  column  is  not  a  lookup  table,  it  represents  a  domain.  For  example,  the  Vehicle  Fleet  field  has  a 
domain  of  “A  15”,  which  means  any  alphanumeric  text  string  up  to  15  characters  in  length.  This  means  you 
are  free  to  give  any  name  you  wish  to  the  Vehicle  Fleet  (no  lookups  are  enforced).  Of  course,  preferably 
the  name  is  descriptive;  in  Figure  3-1  shown  previously,  the  vehicle  fleet  names  tend  to  match  the  start 
node. 


The  field  Number  of  Vehicles  has  a  Domain  of  “Short>=0”,  which  means  a  nonnegative  short  integer 
(values  between  0  and  32,767).  Other  typical  numerical  domains  may  incorporate  ranges,  such  as  “1,99”  or 


GDAS  Algorithm  Description 


3-4 


Database  Design  Guidelines 


“0,99999”  or  “0,15”.  Additional  ranges  include  “Long+/-”  (any  integer),  “Double>=0”  (any  nonnegative 
floating  point  number),  and  “reqqn”  (a  nonnegative  integer  domain). 

The  fourth  column  shown  in  the  Data  Dictionary  is  labeled  “Key?”  and  displays  a  “Y”  if  the  field  is  a  key 
field.  For  the  VehFleet  table,  the  first  three  fields  are  key  fields,  as  indicated  in  the  figure.  GDAS  always 
lists  key  fields  first  for  each  table. 

The  key  fields  of  a  table  may  themselves  be  lookups.  In  the  example,  the  first  two  key  fields  are  lookups 
into  the  parent  VehData  table,  whereas  the  third  key  field  is  a  domain  consisting  of  any  15  character 
alphanumeric  string,  with  no  lookup.  The  non-key  fields  may  also  be  lookups  or  domains. 

Additional  information  in  the  Data  Dictionary  shows  whether  the  field  is  “In”  or  “Out”,  meaning  that  it  is 
either  an  input  to  the  model  or  an  output  from  the  model.  Some  reference  data  is  neither  input  nor  output. 

The  Unit  of  Measure  is  indicated  where  appropriate.  The  Start  Day  Available  field  has  a  unit  of  measure 
indicated  by  “day  (hr)”,  which  means  that  data  input  is  in  whole  days,  but  this  is  converted  to  hours  for  the 
hourly  simulation  used  in  the  model  itself.  In  general,  the  model  performs  all  calculations  in  hours  for 
higher  accuracy  in  travel  times  and  load  rates,  and  to  make  cumulative  differences  in  these  parameters 
visible  for  sensitivity  studies.  Realistically,  however,  the  data  inputs  (availability  day,  required  delivery 
day,  earliest  delivery  day,  etc.)  are  not  accurate  even  to  the  nearest  day,  so  database  inputs  and  outputs  are 
typically  stored  in  days  rather  than  hours. 

Finally,  a  description  of  the  field  is  provided.  All  of  this  information  is  available  on-line,  while  editing  the 
tables,  by  pressing  the  F10  Menu  key,  then  selecting  Help/Data. 

3.9  Database  Hierarchy 

The  lookups  in  the  database  create  a  logical  hierarchy  of  tables  which  define  objects  from  parent  to  child. 
At  the  highest  levels,  the  ultimate  parent  tables  have  few  or  no  additional  lookups,  and  their  key  fields 
define  the  very  basic  reference  objects  of  the  system  that  are  rarely  changed.  Such  basic  reference  tables 
include  the  transport  modes  in  the  Mode  table,  or  the  units  of  measure  in  the  Measure  table,  or  the  cargo 
classes  in  the  CargoCat  table or  the  cargo  categories  in  the  CargoCat  table.  At  an  intermediate  level,  the 
tables  contain  data  that  may  be  expanded  for  a  new  analysis  task,  such  as  adding  a  new  vehicle  type  in  the 
VehType  table  with  new  compartments  in  the  VCptType  table.  The  most  frequently  modified  data  is 
contained  in  the  lower  child  tables,  such  as  the  available  lift  assets  in  the  VehFleet  table,  the  movement 
requirements  and  quantities  in  the  Require  and  ReqQuan  tables,  or  new  intra-theater  facilities  in  the 
Facility  table. 

The  data  tables  can  be  edited  in  any  order,  but  when  adding  new  records  it  is  best  to  work  from  top  down 
in  the  logical  hierarchy.  For  example,  in  the  VehFleet  table  it  is  impossible  to  start  a  new  vehicle  fleet  at  a 
facility  that  does  not  exist  yet.  The  fleet  can  be  created,  and  assigned  temporarily  to  some  existing  facility, 
but  it  cannot  be  assigned  to  a  new  facility  until  that  facility  is  created  in  the  Facility  table. 

To  assist  in  understanding  the  database  hierarchy,  the  complete  set  of  database  tree  diagrams  can  be 
displayed  from  within  the  system  under  the  Tools  menu.  These  tree  diagrams  display  tables  arranged  from 
parent  to  child.  A  hierarchy  example  starting  from  the  Mode  table  is  shown  in  Figure  3-4.  Because  the 
Mode  table  is  basic  to  the  entire  system,  its  hierarchy  tree  is  quite  long  and  shows  most  of  the  tables.  In  the 
figure,  is  can  be  seen  quickly  that  VehFleet  looks  up  into  VehData,  which  looks  up  into  VehType,  which 
looks  up  into  RoutType,  which  looks  up  into  the  ultimate  parent  Mode  table.  The  tree  diagrams  do  not 
provide  additional  information  compared  with  the  Data  Dictionary;  they  simply  sort  the  tables  in  order  of 
lookup  hierarchy. 
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This  depth  of  the  hierarchy  tree  may  look  intimidating,  but  most  of  the  time  you  change  only  the  data  at  the 
lowest  levels,  and  die  parent  tables  act  as  basic  reference  tables.  When  editing,  die  lookups  seem  natural 
since  the  FI  Lookup  key  easily  pops  the  proper  values  into  place.  The  depth  of  the  tree  simply  means  that 
GDAS  is  completely  table  driven.  No  “hard  coding”  is  embedded  in  the  model  to  account  for  different 
modes,  routing  constraints,  vehicle  types,  cargo  categories,  units  of  measure,  etc.  Every  transportation  data 
element  and  constraint  is  defined  in  the  database,  even  to  the  level  of  the  underlying  transport  modes  and 
units  of  measure.  This  table-driven  nature  provides  a  great  deal  of  flexibility  in  tailoring  GDAS  to  your 
study  requirements,  either  at  a  quick  feasibility  level  (Ston  flows),  or  at  a  very  detailed  level  (individual 
unit  equipment  dimensions).  The  only  parts  that  are  “hard  coded”  are  the  scheduling  and  simulation 
algorithms  themselves.  Even  these  can  be  assigned  by  the  user  for  each  mode,  based  on  the  choices  listed 
in  the  display-only  table  SchedTyp. 

3.10  Database  Design  Guidelines 

The  following  standard  database  design  guidelines  have  been  followed  in  structuring  the  GDAS  tables. 

3.10.1  Atomic  Database  Fields/Object  Properties 

Define  atomic  fields,  i.e.  subdivide  fields  until  all  internal  sub-fields  are  explicitly  separated.  All  fields  are 
specified  as  simple  domains  or  as  lookups  to  other  tables.  This  permits  simple  domain  checks,  explicit 
relationships,  simpler  queries,  non-redundant  data. 


3.10.2  Key  Fields 

Every  table  should  be  keyed  to  uniquely  identify  die  records.  Otherwise,  a  query  cannot  distinguish  which 
record  to  update,  duplicate  entries  can  occur,  relationships  cannot  be  enforced,  and  data  checks  cannot  tell 
if  a  duplicate  record  should  be  retained  or  discarded.  Key  field  names  should  be  consistent  throughout  the 
database,  although  some  variations  may  be  permitted  when  multiple  fields  have  different  roles  in  a  single 
table,  such  as  From  Node  and  To  Node  in  the  NodeLink  table. 

3.10.3  No  Data  In  Key  Fields 

Key  fields  provide  a  naming  convention  for  the  user  to  easily  recognize  a  specific  record.  The  database  and 
model  should  NOT  be  sensitive  to  the  contents  of  a  key  field,  since  it  may  be  changed  or  extended,  either 
by  design  enhancements  or  by  the  user.  Another  way  to  state  this  is  that  renaming  the  data  in  a  key  field 
can  be  propagated  automatically  throughout  the  database  with  no  side  effects  in  the  code  itself. 

3.10.4  Relationships 

Define  relationships  as  lookups  from  a  child  table  to  parent  table  keys  that  can  be  enforced  by  the  database 
engine. 

3.10.5  Normalization  and  Non-Key  Data  Fields 

Normalize  non-key  data  attributes  to  depend  on  the  whole  key  and  nothing  but  the  key,  i.e.  put  the  data  in 
the  right  place.  Where  data  elements  have  the  same  key,  the  can  be  merged  into  single  tables  depending  on 
other  factors.  Any  data  that  is  derived  from  other  data  should  not  be  input  by  the  user. 


3.10.6  Repeating  Column  Removal 

Convert  repeating  columns  to  multiple  records.  This  provides  greater  flexibility,  since  new  data  can  be 
added  as  records  rather  than  needing  programmer  changes  to  add  columns.  Plus,  summary  queries  can  be 
performed. 

3.10.7  Separation  of  Inputs  and  Outputs 
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Separate  input  data  from  output  data,  normally  in  separate  tables.  Make  sure  the  user  is  aware  of  which  is 
which. 

3.10.8  Data  Checking 

Specify  data  consistency  rules  using  only  domains,  key  field  uniqueness,  and  key  field  lookups,  where 
possible.  This  permits  the  database  engine  to  implement  many  data  checks  directly,  even  when  data  is 
edited  using  queries. 

3.10.9  Miscellaneous 

GDAS  uses  long  table  names  and  fields  names  for  easier  understanding  by  new  users.  GDAS  excludes 
spaces  in  table  names,  since  databases  like  Paradox  cannot  handle  it,  but  the  Windows  version  does  use 
title  case,  such  as  in  “FacilityType”.  GDAS  does  use  spaces  in  field  names  for  readability,  such  as  “Unit 
Description” 

GDAS  tries  to  have  readable  key  fields,  even  though  this  can  take  more  disk  space  and  have  slower 
indexing  (bookkeeping  is  what  the  computer  is  for,  and  it  remains  fast  for  hundreds  of  thousands  of 
records). 

In  any  case,  no  algorithms  or  queries  are  permitted  to  depend  on  the  specific  contents  of  a  key  field;  any  re¬ 
naming  should  have  no  affect  on  results,  so  user  changes  to  key  fields  and  new  entries  are  safe  in  the 
model.  The  only  exception  is  for  raw  imported  data  from  outside  sources,  where  it  is  often  necessary  to  use 
sub-fields  and  translations. 
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4.  Database  Tables 


4.1  Data  Overview 

The  transportation  data  in  GDAS  can  be  grouped  as  follows: 

•  Transport  Vehicles  and  Lift  Assets,  which  define  the  modes  of  transport,  vehicle  types  for 
transporting  cargo,  compartment  types,  vehicle  characteristics,  and  fleet  availability. 

•  Transportation  Network  Data,  which  define  the  node  locations,  transport  links,  port  facilities,  and 
facility  throughput  constraints. 

•  Movement  Requirements,  which  define  the  quantities  to  be  moved,  the  origins  and  destinations, 
the  ready  to  load  times  and  required  delivery  times,  and  any  required  POEs,  PODs,  and  modes. 

•  Loading  Characteristics,  which  define  the  matching  constraints,  stow  factors  and  load/unload 
rates  for  loading  different  types  of  cargos  on  different  vehicle  types  and  compartments  types  at 
different  facility  types. 

•  Output  Tables,  which  represent  the  output  schedules  and  detailed  simulation  results  for  vehicle 
trips,  stops,  cargos,  as  well  as  summary  data  such  as  cumulative  delivery  profiles. 

•  Special  Topics,  which  define  more  specialized  data  elements  for  convoys,  attrition,  etc. 

The  various  data  tables  and  fields  are  discussed  in  the  sections  following. 

4.2  Transport  Vehicles  and  Lift  Assets 

Figure  4-1  on  the  next  page  provides  an  overview  of  the  GDAS  entities  relating  to  transport  vehicles  and 
lift  assets.  Each  table,  or  object  class,  is  represented  by  a  rectangle  labeled  with  the  table  name.  The  lines 
connecting  the  tables  represent  one-to-many  relationships,  where  the  “crow’s  foot”  symbol  corresponds  to 
the  many  side.  The  dashed  rectangles  represent  tables  that  are  generated  by  the  model  and  not  by  user 
input.  For  example,  in  Figure  4-1,  moving  from  the  upper  left  comer  down  the  diagonal,  the  basic  Mode 
table  lists  the  Transport  Modes;  each  Transport  Mode  can  have  zero,  one,  or  more  Route  Types  which  are 
listed  in  the  RoutType  table;  each  Route  Type  can  have  zero,  one,  or  more  Vehicle  Types  which  are  listed 
in  the  VehType  table;  each  Vehicle  Type  can  have  zero,  one,  or  more  Vehicle  Data  records  listed  in  the 
VehData  table;  each  Vehicle  Data  record  can  have  zero,  one,  or  more  Vehicle  Fleets  available  in  the 
VehFleet  table;  and  each  VehFleet  record  generates  zero,  one,  or  more  distinct  Vehicles  in  the  Vehicle 
table  after  the  model  is  run.  This  hierarchy  defines  the  physical  characteristics  of  the  lift  vehicles  as  well  as 
their  availability.  In  addition,  there  is  an  administrative  hierarchy  that  can  be  used  to  restrict  how  the 
vehicles  are  used  in  planning  and  scheduling.  Again,  from  the  upper  left,  each  Transport  Mode  in  the  Mode 
table  can  have  zero,  one,  or  more  Planning  Fleets  in  the  PlanFlt  table;  each  Planning  Fleet  can  have  zero, 
one,  or  more  Administrative  Fleets  in  the  Fleet  table;  and  each  Fleet  is  associated  with  zero,  one,  or  more 
Vehicle  Fleet  records  in  the  VehFleet  table.  In  addition,  each  Planning  Fleet  can  optionally  have  a  set  of 
pre-scheduled  Standard  Stop  records  in  the  StdStop  table,  often  used  for  cyclical  liner  operations.  The 
various  tables  are  discussed  in  the  paragraphs  following,  with  futher  details  given  in  the  Appendices.  When 
studying  the  data  structures,  it  is  extremely  helpful  to  review  example  tables  such  as  provided  with  GDAS 
in  the  Sample  database  scenario. 

Although  the  number  of  vehicle-related  tables  may  seem  large,  all  the  data  tables  except  the  last  shown  in 
Figure  4-1  provide  generic  “type”  data  which  are  relatively  static  and  do  not  change  from  run  to  run.  For 
example,  the  transport  modes  and  vehicle  types  are  typically  standardized  for  DoD  OPLAN  studies  and 
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change  only  rarely.  In  fact,  many  models  do  not  let  you  change  the  modes  or  vehicle  types  or  compartment 
types  at  all,  and  it  becomes  difficult  to  define  new  vehicle  types.  In  GDAS,  all  data  is  accessible  in  the 
database  tables.  In  die  figure,  the  only  table  which  does  typically  change  for  different  runs  is  the  VehFleet 
table  which  establishes  the  availability  of  different  transport  vehicle  lift  assets. 
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Figure  4-1.  Data  Tables  and  Relationships  for  Transport  Vehicle  Lift  Assets 

4.2.1  Transport  Mode 

The  Mode  table  lists  the  transportation  modes  that  are  available  for  delivering  cargo.  Typical  modes  of 
transport  include  Airlift,  Sealift,  Truck,  Rail,  Pipeline,  and  InPlace.  At  a  more  detailed  level,  modes  might 
include  facility  transfers  such  as  Crane,  Forklift,  Containerization,  etc.  These  modes  can  be  created, 
deleted,  or  renamed  as  desired  for  a  particular  study.  In  GDAS,  the  concept  of  mode  represents  a  basic 
partitioning  of  transportation  links  and  facilities  into  separate  sub-networks  on  which  only  the  matching 
transport  vehicles  or  lift  assets  can  travel.  For  example,  Airlift  and  Sealift  are  different  modes  so  they 
cannot  travel  on  the  same  network  links.  Similarly,  if  strategic  airlift  and  theater  airlift  are  to  fly  on  the 
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same  links  and  compete  for  the  same  airport  facilities,  then  they  must  be  assigned  a  common  mode  of 
transport  such  as  Airlift.  As  discussed  later,  each  transportation  link  in  the  network  and  each  facility  at  a 
node  are  assigned  a  single  mode  of  transport. 


Data  elements  stored  in  the  Mode  table  are  listed  in  Figure  4-2. 


Field  Name 

Description 

1  Transport  Mode 

2  Scheduling  Model 
Type 

Name  of  a  transport  mode  (e.g.  Airlift,  Sealift,  Rail,  Motor,  Pipeline, 

Generic,  etc.)  _ _ _ 

Scheduling  model  algorithm  type  used  for  this  mode  of  transport 

3  ASCII  Code 
Abbreviation 

4  Letter  for  Model 
Display 

ASCII  code  of  a  single  upper  case  letter  abbreviation  used  by  the  modei  to 
display  on-screen  activity  progress  (S  for  Sea,  A  for  Air,  etc.,  with  lower 

case  for  planning  and  upper  case  for  scheduling  and  simulation)  _ 

Single  letter  for  this  mode,  used  to  display  progress  during  model 
execution  (most  useful  if  the  letters  are  unique  across  modes) 

Figure  4-2.  Data  Elements  for  the  Mode  Table 


4.2.2  Scheduling  Model  Type 

Each  transport  mode  listed  in  the  Mode  table  is  assigned  a  Scheduling  Model  Type,  which  determines  how 
GDAS  performs  scheduling  for  that  mode.  The  available  scheduling  models  are  organized  in  the 
SchedType  table  by  level  of  detail,  ranging  from  the  most  detailed  Multiport  Algorithm  to  the  simplest 
Travel  Time  algorithm  as  shown  in  Figure  4-3.  For  large  discrete  lift  assets,  such  as  ships,  the  mode 
detailed,  multi-trip,  multi-port  scheduling  algorithm  is  recommended  unless  the  movement  requirements 
are  packaged  or  aggregated  up  to  reasonably  fiill  ship  loads.  For  aircraft,  which  often  have  capacities  much 
smaller  than  a  single  movement  requirement,  the  Pickup  Deliver  algorithm  is  somewhat  faster  but  still 
quite  detailed,  tracking  discrete  multiple  trips  each  with  a  single  pickup  and  delivery  airport,  but  allowing 
for  multiple  cargo  loads  at  each  POE  and  POD.  Truck  and  Rail  are  also  suitable  for  the  Pickup  Deliver 
model,  particularly  if  vehicle  sizes  are  aggregated  to  represent  truck  convoys  and  trains.  The  Vehicle  Flow 
model  allocates  limited  vehicle  capacity  and  available  hours  to  various  movement  channels,  but  does  not 
track  each  vehicle  location  precisely  over  time.  The  Travel  Time  algorithm  is  the  least  detailed  algorithm; 
it  computes  travel  and  loading  times  assuming  unconstrained  vehicle  availability  and  determines  the 
number  of  trips  required.  All  of  the  scheduling  algorithms  take  into  account  node  and  facility  throughput 
constraints. 


Scheduling 

Algorithm 

Level  of 
Detail 

Description 

Multiple  Ports 

Very 

High 

Tracks  each  vehicle  trip  with  multiple  pickups  and  deliveries, 
schedules  using  detailed  route  insertion 

Pickup  Deliver 

High 

Tracks  each  vehicle  trip  with  a  single  pickup  and  deliveiy,  schedules 
new  trips  at  the  end. 

Vehicle  Flow 

Medium 

Schedules  trips  with  limited  vehicles  by  allocating  available  vehicle 
hours  to  trip  cycle  times  without  tracking  individual  vehicle  locations. 

Travel  Time 

Low 

Performs  travel  time  calculations  and  assumes  sufficient  vehicles  are 
available  when  needed. 

Figure  4-3.  GDAS  Scheduling  Algorithms 


4.2.3  Vehicle  Type 

Within  a  mode  of  transport,  the  lift  assets  for  moving  cargo  are  classified  by  Vehicle  Type  in  the  VehType 
table.  For  example,  the  Airlift  mode  typically  has  vehicle  types  such  as  C-141,  C-5a,  C-5b,  C-130,  B-747, 
etc.  For  sealift,  typical  vehicle  types  include  Breakbulk,  RORO  (roll-on  roll-off),  Container,  Fast  Sealift, 
etc.  The  Vehicle  Type  represents  a  grouping  of  lift  assets  or  transport  vehicles  that  share  general  loading 
characteristics,  such  as  type  of  compartments,  type  of  facilities  that  can  be  used,  matching  of  cargo  that  can 
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be  loaded,  stow  factors,  load/unload  rates,  and  routing  constraints.  If  any  of  these  characteristics  are  not 
shared  in  common,  then  new  vehicle  types  need  to  be  added.  Other  detailed  characteristics,  such  as  speed 
and  payload,  may  vary  by  individual  vehicle  within  a  Vehicle  Type  and  are  specified  in  the  VehData  table. 


Field  Name 

Description 

1  Vehicle  Type 

Vehicle  type  name,  e.g.  Breakbulk  for  sealift,  C-17  for  airlift,  etc. 

2  Route  Type 

Route  type  to  use  for  this  vehicle  type 

3  Arrive/Depart  Time 

Combined  total  additional  time  for  node  arrival  and  departure  for  this  vehicle  type,  such 
as  takeoff/landing  time  or  port  maneuver  time  (adds  to  travel  time  and  reduces  the 
average  block  speed,  but  does  occur  not  affect  facility  parking) 

4  Vehicle  Standard  Size 
%_ 

5  Time  Penalty 

Size  of  vehicle  relative  to  “standard”  vehicle  size,  may  exceed  100%  for  larger  vehicles, 
used  for  allocating  facility  berths  or  parking  spaces  (MOG) 

Penalty  for  vehicle  usage  per  hour,  used  to  compare  with  cargo  lateness  in  the  scheduling 
algorithm 

Limit  on  the  acceptable  cost/benefit  ratio  for  a  greedy  vehicle  trying  to  get  additional 
cargo  immediately  after  an  assignment 

Attrition  adjustment  multiplier  applied  to  the  link  attrition  or  breakdown  rate  for  this 
vehicle  type  while  in  transit  (blank  or  0  is  treated  as  100%) 

8  Node  Attrit  Multiplier 
% 

Attrition  adjustment  multiplier  applied  to  the  node  attrition  or  breakdown  rate  for  this 
vehicle  type  while  at  the  node  (blank  or  0  is  treated  as  100%) 

9  Attrit  Partial  Damage  % 

Percent  of  attritted  or  broken  down  vehicles  which  are  partially  damaged  and  can  be 
repaired 

10  Repair  Days 

1 1  Replace  Days 

Delay  days  for  repair  of  a  partially  damaged  vehicle,  after  which  the  vehicle  continues  its 
scheduled  itinerary 

Nonzero  vehicle  replacement  time  at  the  initial  ALD  node  after  total  attrition  (if  blank, 
no  replacement  occurs) 

Figure  4-4.  Data  Elements  for  the  Vehicle  Type  Table  (VehType). 


4.2.4  Route  Type 

Each  Vehicle  Type  is  assigned  a  single  Route  Type  from  the  RoutType  table.  A  Route  Type  is  associated 
with  a  single  mode  of  transport  and  is  used  to  determine  which  links  a  particular  kind  of  Vehicle  Type  can 
travel  on.  Different  Vehicle  Types  can  generally  travel  on  matching  links  that  have  the  appropriate 
transport  Mode,  but  the  routes  and  links  actually  taken  can  be  affected  by  critical  leg/payload  tradeoffs  (for 
airlift)  and  canal  constraints  (for  sealift). 

In  GDAS,  a  “route”  consists  of  a  sequence  of  travel  links  and  intermediate  nodes  from  one  facility  to 
another  facility  for  a  single  mode  of  transport.  A  Route  Type  as  listed  in  die  RoutType  table  specifies  the 
routing  characteristics  that  determine  which  of  several  available  routes  is  most  suitable.  Several  route  type 
can  apply  to  the  same  mode  and  share  the  same  network  links,  but  have  different  routing  factors  such  as 
refueling  feasibility  at  intermediate  nodes,  link  compatibility  such  as  canal  constraints,  and  payload  versus 
critical  leg  distance  tradeoffs.  These  variations  in  Route  Type  permit  some  vehicles  to  have  different  routes 
with  different  travel  times,  even  though  they  share  the  same  transport  mode  and  network  links. 
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Field  Name 

Units 

Description 

1  Route  Type 

Route  type  for  computing  vehicle  paths  _ 

2  Transport  Mode 

Transport  mode  for  this  route  type  _ 

3  Speed  to  Convert  Delays 

nmi/hr 

Nominal  routing  speed  which  is  used  to  convert  link  delays  and  refueling  delays 
to  equivalent  distances  for  routing,  in  nautical  mph 

4  Range  at  Max  Payload 

nmi 

Range  or  critical  leg  distance  corresponding  to  the  maximum  allowed  payload, 
in  nautical  miles 

5  Payload  Decrease  %/kmi 

%/1000n 

mi 

Percent  decrease  in  payload  per  1000  nautical  miles  of  increase  in  critical  leg 
distance  beyond  the  max  payload  range 

6  Refuel  Arrive/Depart  Time 

hr 

Arrival  and  depart  time  delays  for  refueling  (e.g.,  landing  and  takeoff  delays) _ 

7  Refuel  Time 

hr 

Refueling  time  in  the  facility 

8  Required  Link  Rating 

User-definable  link  rating  required  for  each  link  in  a  feasible  path  for  this  route 
type;  for  example,  for  sealift  the  Required  Link  Rating  may  represent  ship  draft, 
which  cannot  exceed  the  Link  Rating  (link  draft)  of  any  link  on  a  feasible  path 

9  Refuel  Fac  Length  Req 

ft 

Facility  length  required  for  refueling 

10  Refuel  Fac  Width  Req 

ft 

Facility  width  required  for  refueling 

1 1  Refuel  Fac  Dimension 

Req 

varies 

Facility  dimension  required  for  refilling  (e.g.,  draft  for  sea) 

12  Refuel  Fac  Rating  Req 

varies 

Facility  rating  level  required  for  refueling  (e.g.,  LCN  or  landing  classification 
number  for  air,  boom  capacity  for  sea) 

Figure  4-5.  Data  Elements  for  the  Route  Type  Table  (RoutType). 


4.2.5  Refueling  Constraints  and  Payload  Affects 

Refueling  is  an  important  consideration  for  vehicles  such  as  aircraft,  when  range  is  limited  and  the  payload 
may  depend  on  the  “critical  leg”,  which  is  the  longest  travel  distance  between  refueling  points.  In  such 
cases,  a  tradeoff  exists  between  refueling  more  frequently  with  higher  payloads  and  slower  travel  times, 
versus  refueling  less  frequently  with  lower  payloads  and  faster  travel  times.  If  the  Range  at  Max  Payload 
exceeds  the  travel  distance  (e.g.,  for  ships)  then  GDAS  does  not  model  refueling.  If  the  Payload  Decrease 
is  zero,  the  range  becomes  a  routing  constraint  but  does  not  affect  the  allowable  payload.  If  the  Payload 
Decrease  is  nonzero,  then  GDAS  models  the  payload  dependencies  using  a  piecewise  linear  approximation 
as  shown  in  Figure  4-6.  For 
instance,  a  C-5  Route  Type 
may  have  the  following 
characteristics:  Range  at 
Max  Payload  of  2000  miles, 
and  Payload  Decrease  of 
12%/kmi  after  exceeding  the 
initial  2000  miles,  as  shown 
in  the  figure  (“kmi”  denotes 
1000  miles).  If  the  “critical 
leg”  distance  on  one  or  more 
links  between  refueling 
points  is  3000  miles,  then 
the  payload  is  reduced  by 
the  following  calculation: 


Payload 


Figure  4-6.  Payload  Percentage  Versus  Critical  Leg  Distance  Between  Refueling 
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Payload  Reduction  %  = 

=  (Critical  Leg  Distance  -  Range  at  Max  Payload)*(Payload  Decrease  %/kmi)  /  (1000  mi/kmi) 
=  (3000mi  -  2000mi)  *  (12%/kmi)  /  (1000  mi/kmi) 

=  12  %  reduction. 

The  allowable  payload  is  therefore  88%  of  the  maximum  for  traveling  3000  miles  without  refueling.  For  an 
empty  aircraft  on  a  return  flight,  the  maximum  range  when  flying  empty  is  given  by: 

Empty  range  =  Range  at  Max  Payload  +  100%  Reduction^  lOOOmi/kmi)  /  (Payload  Decrease  %/kmi) 

=  2000mi+  100%*(1000mi/kmi)  /  (12%/kmi) 

=  10,333  mi. 

It  should  be  noted  that  a  loaded  route  may  be  different  from  an  unloaded  empty  route  because  the  aircraft 
refuels  more  frequently  on  the  loaded  route  to  carry  the  cargo  payload. 

Different  aircraft  may  have  different  Route  Types  with  different  refueling  characteristics,  so  that  they  may 
travel  on  different  routes.  In  determining  the  “best”  route,  GDAS  evaluates  alternative  links,  nodes,  link 
constraints,  refueling  points,  refueling  times,  landing/takeoff  times,  critical  leg  distances,  and  payloads  to 
maximize  the  overall  payload  delivered  per  unit  time.  The  routing  algorithm  is  one  of  the  more 
sophisticated  components  of  the  model. 

For  Route  Types  that  do  model  refueling,  various  facility  types  can  be  excluded  for  refueling  using  the 
RoutExcl  table.  An  additional  consideration  is  that  an  aircraft  may  not  be  able  to  refuel  at  a  POD  based  on 
the  refuel  exclusions  in  RoutExcl,  so  a  recovery  base  must  be  found  prior  to  refueling. 


4.2.6  Vehicle  Data 

For  each  Vehicle  Type,  there  can  be  multiple  Vehicle  Data  records  in  the  VehData  table.  Whereas  the 
Vehicle  Type  defines  the  general  routing  properties,  generic  loading  factors,  and  the  types  of 
compartments,  the  Vehicle  Data  record  specifies  the  individual  vehicle  characteristics  such  as  Cruising 
Speed,  Facility  Length  Required,  Max  Cargo  Load  in  Ston,  etc.  For  sealift,  each  Vehicle  Data  record  in 
VehData  typically  represents  a  single  unique  ship,  since  each  ship  has  its  own  unique  characteristics.  Thus, 
there  may  be  many  ships  having  a  Vehicle  Type  of  Breakbulk,  each  ship  being  listed  in  VehData  with 
unique  characteristics.  For  airlift,  at  the  other  extreme,  each  Vehicle  Data  record  may  simply  correspond  to 
the  Vehicle  Type  itself,  since  all  C-141  or  C-5a  aircraft  share  the  same  cruising  speed,  etc.  In  this  case, 
there  may  be  only  one  VehData  record  or  a  few  variations  for  a  given  Vehicle  Type. 


Field  Name 

Units 

Description 

Vehicle  Type 

— 

Vehicle  type  name  _  _ 

Vehicle  Identifier 

■ 

Vehicle  identifier  for  Sis  vehicle  data 

Cruising  Speed 

nmi/hr 

Cruising  speed  of  Sis  vehicle,  in  nautical  mph 

Max  Cargo  Load 

Ston 

Maximum  allowed  cargo  load  over  all  compartments  for  Sis  vehicle,  in  ston 

Facility  Length  Required 

Ft 

Facility  length  required  for  loading  and  unloading 

Facility  Width  Required 

Ft 

Facility  width  required  for  loadingand  unloading _ _  _ 

Facility  Dimension 

Required 

Varies 

Facility  dimension  required  (user-definable,  e.g.,  draft  for  sea) 

Facility  Rating  Required 

Varies 

User-definable  facility  rating  required  for  loading  and  unloading  (e.g.,  landing 
classification  number  for  air,  boom  capacity  for  sea) 

Figure  4-7.  Data  Elements  for  the  Vehicle  Data  Table  (VehData). 
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4.2.7  Vehicle  Fleet 

The  Vehicle  Fleet  records  in  the  VehFleet  table  list  the  actual  availabilities  of  vehicles  by  location,  starting 
time,  and  number  of  vehicles.  For  sealift,  each  ship  may  be  assigned  a  unique  location  and  starting 
availability  with  the  Number  of  Vehicles  set  to  one.  For  smaller  transport  vehicles,  numerous  vehicles  may 
be  “cloned”  as  a  fleet  or  squadron  of  vehicles  that  are  available  at  a  single  location  and  starting  time  (this 
can  also  be  done  with  sealift  if  you  wish  to  quickly  clone  one  or  more  ships).  If  vehicles  have  different 
starting  locations  or  times  then  they  must  be  entered  as  additional  Vehicle  Fleet  records;  several  different 
Vehicle  Fleet  records  can  reference  the  same  Vehicle  Data  record  in  the  VehData  table. 


The  Fleet  table  that  is  also  shown  in  the  figure  is  computed  from  the  VehFleet  table  and  is  not  entered 
directly.  It  simply  lists  the  unique  Fleet  values  entered  into  the  VehFleet  table.  The  purpose  of  the  Fleet 
table  is  to  provide  a  lookup  for  excluding  fleets  from  specified  theaters,  nodes,  or  requirement  types. 


Field  Name 

Units 

Description 

Vehicle  Type 

Vehicle  type 

Vehicle  Identifier 

Vehicle  identifier,  such  as  ship  name  or  aircraft  squadron,  for  this  starting 
location,  vehicle  type,  and  fleet 

Vehicle  Fleet 

Fleet  identifier  for  this  starting  location 

Number  of  Vehicles 

Number  of  vehicles  in  the  fleet  for  this  vehicle  type 

Start  Scheduling  Day 

day  (hr) 

Administrative  day  that  this  fleet  and  vehicle  type  are  first  available  for 
scheduling  new  trips,  stops,  and  cargo 

Stop  Scheduling  Day 

day  (hr) 

Stop  day  after  which  this  fleet  and  vehicle  type  are  returned  to  its  starting  node 
or  route  with  no  more  use  (blank  or  0  is  treated  as  available  through  the 
simulation  end  date) 

Start  Node 

Starting  home  base  node  for  this  fleet  and  vehicle  type  (a  vehicle  starts  at  and 
returns  to  its  home  base  if  not  otherwise  assigned) 

Start  Facility 

Starting  home  base  facility  for  this  fleet  and  vehicle  type  (a  vehicle  starts  at  and 
returns  to  its  home  base  if  not  otherwise  assigned) 

day 

Offset  day  for  this  fleet  and  vehicle  for  a  standard  prescheduled  starting  route 
cycle 

Start  Route  Last  Day 

day  (hr) 

Last  day  beyond  which  the  prescheduled  starting  route  is  no  longer  cycled 

Special  Mission 

Special  mission  which  restricts  this  fleet  to  matching  special  mission  movement 

requirements  for  a  designated  period  of  time 

New  Vehicle  Penalty 

$/new  veh 

Penalty  for  the  first  use  of  a  new  vehicle  of  this  type  and  fleet 

Call  Sign 

International  call  sign  or  identifier  of  the  vehicle  and  fleet 

Other  Identifier 

Other  identifier  such  asNISC  (Naval  Intelligence  Security  Code)  for  the  vehicle 

and  fleet  _ 

Requirement 

Requirement  by  which  this  vehicle  fleet  is  delivered  (these  vehicles  are  not 

available  until  the  requirement  is  completely  delivered) 

Figure  4-8.  Data  Elements  for  the  Vehicle  Fleet  Table  (VehFleet). 


4.2.8  Planning  Fleet 

The  PlanFlt  table  is  used  to  group  similar  sub-groups  of  vehicles  within  a  Transport  Mode  into  Planning 
Fleets  for  evaluation  by  the  planning  algorithm.  This  makes  it  is  possible  to  specify  different  planning 
fleets  within  a  mode  for  tracking  vehicle  capacity  and  facility  capacity  during  planning,  since  planning 
does  not  assign  individual  vehicles.  All  of  the  planning  factors,  such  as  Planning  Speed  and  Planning  Ton- 
Hour  Penalty,  are  now  consolidated  in  the  more  PlanFlt  table,  as  summarized  in  the  attached  dictionary 
elements. 

Previously,  planning  was  based  on  modes,  so  that  the  planning  algorithm  selected  the  end-to-end  modes  (in 
addition  to  nodes  and  configurations),  and  passed  this  information  to  scheduling.  This  captures  major 
vehicle  characteristics  and  in  many  cases  this  approach  may  still  be  appropriate.  In  fact  the  default  GDAS 
test  scenario  has  one  Planning  Fleet  for  each  Mode.  For  example,  a  “Sealift”  planning  fleet  is  defined  for 
the  “Sealift”  mode. 
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More  recently,  the  new  planning  algorithm  adds  tracking  of  vehicle  capacity  constraints,  in  addition  to 
node/facility  capacity.  Planning  still  uses  a  cargo  flow  model  prior  to  scheduling,  but  both  the  facility  and 
vehicle  capacity  constraints  are  tracked  over  time  as  each  cargo  is  planned  for  movement  during  specific 
time  intervals.  Planning  does  not  assign  individual  vehicles  using  detailed  multi-port  itineraries,  which  is 
performed  in  scheduling.  But  planning  does  make  alternative  decisions  based  on  the  total  capacity 
available  for  different  units  of  measure,  vehicle  compartment  capacity,  and  facility  throughput.  Because 
different  vehicles  can  load  different  amounts  of  cargo,  the  planning  process  cannot  simply  count  the 
number  of  vehicles  needed.  Instead,  planning  evaluates  the  amount  of  cargo  that  can  be  loaded,  which 
means  it  must  track  key  loading  factors  including  multiple  units  of  measure  (Mton,  SqFt,  etc.),  stow 
factors,  cargo-vehicle-facility-compartment  matching,  and  estimated  timing. 


Field  Name 

Units 

Description 

1  Planning  Fleet 

Aggregation  of  fleets  used  for  planning  modes,  ports,  cargo  configurations,  and 
prescheduled  routes  . 

2  Fleet  Mode 

Transport  mode  used  by  the  planning  fleet 

3  Transport  Agent 

4  Planning  Speed 

nmi/hr 

Transportation  agent  or  company  identifier  for  this  fleet 

Nominal  planning  speed  in  nautical  mph  or  knots  for  planning  routes  and  target 
lift  dates  (this  is  a  planning  speed,  not  a  scheduling  or  simulation  speed,  and 
should  be  set  to  match  slower  vehicles) 

5  Planning  Delay  Hours 

hr 

Nominal  planning  delay  time  in  hours  for  each  mode  change  to  allow  for  vehicle 
repositioning,  loading,  unloading,  and  other  delays  for  planning  routes  and 
target  lift  dates  (accounts  for  repositioning  in  planning,  not  just  load  times) 

6  Planning  Ton-Hour  Penalty 

$/hr/ton 

Nominal  penalty  per  ton  per  hr  for  transport  via  this  vehicle  type  for  planning 
routes  and  target  lift  dates  _ 

7  Plan  Fleet  Productivity  % 

%  of  C- 
mi/day 

Plan  fleet  useful  planning  percent  allocation  or  productivity  %,  expressed  as  a 
percent  of  transport  lift  flow  capacity  (Mton-mi/day,  SqFt-mi/day,  etc.)  as 
contributed  by  die  first  measure  of  each  compartment 

8  Utilization  Rate  % 

% 

Vehicle  effective  utilization  (UTE)  rate  expressed  as  a  percent  usage  per  day 
based  on  maintainability,  logistics  support,  re-basing,  non-productive  use 
(applies  to  travel  time  only,  not  time  in  port,  and  cause  recovery  delays  after 
trips'! 

9  Greedy  Vehicle  Wait 

hr 

Max  wait  time  for  evaluating  additional  cargo  at  the  same  POE  after  an 
assignment,  used  in  the  vehicle  scheduling  algorithm 

10  Standard  Depart  Interval 

1 1  Stop  Arrival  Tolerance 

day 

day  (hr) 

Standard  depart  time  interval  for  a  prescheduled  route,  stored  for  reference  only 
and  not  used  to  generate  routes 

Time  window  tolerance  for  early  or  late  arrival  at  the  prescheduled  stops  on  this 
route  _ _ 

12  Route  Delay  Penalty 

Penalty  for  the  delay  of  prescheduled  stops  when  inserting  new  stops,  the  input 
value  is  the  penalty  of  one  day  delay  in  cents,  with  increasing  cost  for  greater 
delays 

13  Remain  On  Route? 

T/F 

Checked  or  True  if  the  prescheduled  ship  should  stay  on  its  prescheduled  route 
only  up  through  the  Route  Last  Day,  otherwise  False _ _ _ _ 

14  Description  _ _ 

Description  of  the  prescheduled  route 

Figure  4-9.  Data  Elements  for  the  Planning  Fleet  table  (PlanFlt). 


The  planning  fleets  offer  better  control  over  the  planning  process  rather  than  using  modes  alone.  For 
example,  strategic  airlift  and  theater  airlift  may  share  die  same  travel  links  and  facilities,  but  their  capacity 
is  assigned  to  very  different  cargo  movement  legs.  In  order  for  planning  to  see  the  proper  allocation  of 
airlift  capacity,  it  may  be  appropriate  to  create  two  planning  fleets,  one  for  strategic  airlift  and  one  for 
intra-theater  airlift.  This  avoids  pooling  the  intra-theater  airlift  capacity  with  strategic  airlift  during 
planning,  and  is  also  useful  for  restricting  them  to  specific  theaters.  Based  on  the  planning  fleets  and  their 
constraints,  the  planning  algorithm  then  selects  nodes,  configurations,  modes,  AND  planning  fleets  for 
subsequent  scheduling.  A  similar  situation  occurs  with  multi-theater  scenarios,  in  which  different  fleets  of 
vehicles  may  be  pre-allocated  to  different  theaters. 
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As  another  example,  the  use  of  Fast  Sealift  ships  may  have  special  planning  considerations  different  from 
other  sealift,  e.g.  fast  sealift  may  be  dedicated  to  Army  unit  moves.  Since  planning  evaluates  limits  on  the 
ship  capacity,  it  may  be  important  to  track  limited  Fast  Sealift  capacity  separate  from  other  ships  during 
planning  Otherwise,  planning  does  not  track  the  use  of  Fast  Sealift  capacity  as  a  separate  lift  asset  distinct 
from  other  ships.  Die  planning  fleets  provide  additional  guidance  about  efficiently  using  a  limited  number 
of  special  lift  assets  relative  to  high  priority  movements. 

The  use  of  planning  fleets  can  increase  or  decrease  run  time.  If  the  planning  fleets  have  distinct  constraints 
relative  to  die  modes  as  a  whole,  then  making  planning  fleets  more  detailed  can  reduce  run  time  because 
capacity  reservations  are  tracked  in  separate  smaller  lists  rather  than  one  large  list  for  each  mode.  The 
planning  fleets  also  reduce  subsequent  scheduling  time,  since  fewer  vehicle  alternatives  exist  with  each 
planning  fleet  during  the  scheduling  process.  On  die  other  hand,  the  use  of  multiple  planning  fleets  having 
similar  characteristics  can  definitely  increase  planning  time  and  unduly  constrain  the  scheduling 
alternatives.  In  summary,  the  planning  fleets  should  be  used  as  “more  detailed  modes”  to  separate  groups 
of  vehicles  that  have  significantly  different  deployment  considerations. 

4.2.9  Prescheduled  Stops 

Each  Planning  Fleet  can  be  assigned  a  prescheduled  stop  itinerary,  including  cyclical  liner  routes  that  are 
automatically  duplicated  and  expanded  into  multiple  trips.  Prescheduled  stops  are  defined  in  the  StdStop 
table  using  the  data  elements  shown  in  Figure  4-10.  Any  prescheduled  stops  that  are  defined  and  associated 
with  vehicle  availability  in  the  VehFleet  table,  are  generated  and  expanded  prior  at  the  beginning  of  the 
model  run  and  are  retained  in  the  final  schedule.  For  example,  the  DOD  Voluntaiy  Intermodal  Sealift 
Agreement  (VISA)  program  makes  uses  of  commercial  liner  routes  which  have  preset,  cyclical  itineraries. 
Several  ships  in  VehFleet  may  be  assigned  to  the  same  prescheduled  stops  in  StdStop  using  the  Start  Route 
Id,  but  with  different  Start  Route  Offset  as  specified  in  VehFleet.  If  the  prescheduled  stops  are  cyclical 
(they  start  and  stop  at  the  same  node),  then  the  prescheduled  itinerary  is  automatically  repeated  over  time 
until  the  end  of  the  simulation,  or  until  the  Start  Route  Last  Day  specified  in  VehFleet. 


Field  Name 

Description 

1  Planning  Fleet 

Planning  fleet  that  has  prescheduled  stops 

2  Stop  Sequence 

Stop  sequence  number  for  this  prescheduied  planning  fleet  (stops  are 

3  Arrive  Day 

Arrive  day  offset  for  this  prescheduled  stop  sequence,  starting  from  zero  (the 

4  Node 

Node  associated  with  this  prescheduied  stop  sequence  number 

5  Facility 

Facility  associated  with  this  prescheduled  stop  sequence  number 

6  Depart  Day 

Departday  offset  for  this  prescheduied  stop  sequence,  starting  from  zero 

Figure  4-10.  Data  Elements  for  the  Standard  Prescheduled  Stop  table  (StdStop). 


4.2.10  Compartment  Type 

A  Compartment  Type  in  die  CptType  table  is  used  to  represent  a  kind  of  cargo  stowage  capability  for 
loading  cargo  on  a  transport  vehicle.  A  vehicle  can  have  multiple  compartment  types  for  loading  cargo.  For 
example,  a  Breakbulk  ship  typically  has  a  “Deck”  compartment  and  a  “Hold”  compartment,  which  have 
different  cargo  loading  characteristics  but  reside  on  the  same  ship.  The  Compartment  Type  is  used  to 
define  compatibility  with  different  cargo  types,  units  of  measure  for  capacity  calculations,  and  stowage 
factors  for  loading  die  cargo.  Each  Compartment  Type  is  applicable  to  a  single  Transport  Mode  only,  and 
different  Compartment  Types  must  be  defined  for  different  modes.  A  Compartment  Type  can  be  used  on 
different  Vehicle  Types  within  a  mode.  For  example,  the  “Deck”  compartment  type  may  be  applicable  to 
several  different  ship  types,  but  if  a  compartment  has  different  stow  factors  then  it  must  be  defined  as  a 
different  Compartment  Type  record. 
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Field  Name 

Description 

1  Compartment  Type 

Generic  compartment  type  name  which  is  associated  with  stow  factors  and 
vehicle  capacities  (e.g..  Hold  for  ships,  Outsize  for  aircraft.  Boxcar  for  rail. 
Flatbed  for  motor)  _ _ _  _ _ _ _ 

2  Transport  Mode 

Transport  mode  associated  with  this  compartment  type  _ 

Figure  4-11.  Data  Fields  for  the  Compartment  Type  table  (CptType). 


4.2.11  Vehicle  Compartment  Type 

Since  a  vehicle  can  have  multiple  compartments,  the  VCptType  table  specifies  the  allowable  Compartment 
Types  for  each  Vehicle  Type.  All  vehicles  within  a  single  Vehicle  Type  have  the  same  Compartment  Types 
(otherwise,  a  new  Vehicle  Type  must  be  defined).  For  example,  a  Vehicle  Type  of  “Breakbulk” 
representing  breakbulk  ships  may  have  two  applicable  Compartment  Type  records,  “Deck”  and  Hold  ,  as 
listed  in  the  VCptType  table.  This  means  that  all  “Breakbulk”  vehicles  have  the  two  compartment 
capacities  listed  in  the  VehCap  table  (see  below),  although  the  compartment  capacity  can  be  zero  to 
exclude  loading  in  those  exceptions  where  no  usable  deck  space  exists. 


Field  Name 

Description 

1  Vehicle  Type 

Vehicle  Type  (e.g.  C-5  for  air;  Breakbulk  for  sea;  Van,  Flatbed,  Special, 

Refrigerated,  etc.  for  motor;  Flatcar  for  Rail) 

2  Compartment  Type 

Name  of  an  available  compartment  type  for  the  vehicle  type 

Figure  4-12.  Data  Fields  for  the  Vehicle  Compartment  Type  Table  (VcptType). 


4.2.12  Compartment  Measure 

In  order  to  compute  the  amount  of  cargo  that  can  be  loaded  on  a  vehicle  compartment,  the  capacity  of  the 
compartment  must  be  entered  in  appropriate  units  of  measure.  The  Compartment  Measure  table  CptMeas  is 
used  to  define  which  units  of  measure  apply  to  each  Compartment  Type.  A  single  compartment  can  have 
multiple  units  of  measure  (e.g.,  Mton  and  SqFt)  either  of  which  can  be  constraining  depending  on  the 
volume  and  area  density  of  the  cargo.  Depending  on  stow  factors  and  the  cargo  quantities,  one  cargo  may 
“cube  out”  and  a  different  cargo  may  “square  out”  when  loading  the  same  vehicle  compartment.  The 
CptMeas  table  defines  which  measures  apply.  For  example,  a  sealift  “Deck”  compartment  may  have  only  a 
single  constraining  unit  of  measure  for  area  (SqFt),  whereas  an  airlift  “C-17”  compartment  may  have  both 
volume  (Mton)  and  area  (SqFt)  capacity  limits  for  the  same  compartment  space. 


The  CptMeas  table  assigns  measures  to  compartments  based  on  the  allowable  measures  in  the  Measure 
table.  New  measures  can  be  defined  as  appropriate  for  use  in  GDAS;  for  example,  a  TEU  measure  can  be 
defined  to  measure  the  capacity  of  “Container”  compartments. 


Field  Name 

Description 

1  Compartment  Type 

Compartment  type  name  used  to  specify  stow  factors  for  vehicle  types  and 
capacities  for  vehicles 

2  Compartment  Measure 

Unit  of  measure  for  defining  compartment  capacity  (in  addition  to  the  total  Ston 
measure  which  is  always  used  for  each  vehicle) 

Figure  4-13.  Data  Fields  for  the  Compartment  Measure  Table 


4.2.13  Vehicle  Compartment  Capacity 

The  Vehicle  Compartment  Capacity  table,  VehCap,  lists  the  compartment  capacities  for  every  Vehicle 
Data  record,  matching  Compartment  Type,  and  matching  Compartment  Measure.  The  user  need  enter  only 
the  actual  capacity  data.  All  of  the  records  and  key  fields  in  the  VehCap  table  are  derived  from  the  other 
VehData,  VCptType,  and  CptMeas  tables  and  are  filled  out  automatically. 
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Field  Name 

Description 

1  Vehicle  Type 

Vehicle  type 

2  Vehicle  Identifier 

Vehicle  identifier  for  this  vehicle  data 

3  Compartment  Type 

Compartment  type  for  this  vehicle  type 

4  Compartment  Measure 

Compartment  stowage  measure 

5  Capacity 

Stowage  capacity  for  this  vehicle  compartment  in  the  stowage  measure 

Figure  4-14.  Data  Elements  for  the  Vehicle  Capacity  Table  (VehCap). 


4.2.14  Vehicle 

The  Vehicle  table  is  derived  from  VehFleet  and  is  not  input  data.  The  table  is  shown  here  only  for 
reference.  The  GDAS  scheduling  model  tracks  each  Vehicle  separately,  so  as  a  first  step  it  takes  each 
VehFleet  record  and  “clones”  the  individual  vehicles  based  on  the  Number  of  Vehicles  available.  One  of 
the  outputs  of  the  model  is  a  complete  listing  of  each  unique  Vehicle,  with  many  of  the  vehicles  having  the 
same  characteristics  but  different  scheduled  trips,  stops,  and  cargos. 


Field  Name 

Units 

Description 

1  Vehicle  Number 

Vehicle  unique  sequential  number 

2  Vehicle  Type 

Vehicle  type  j 

3  Vehicle  Identifier 

Vehicle  identifier 

4  Vehicle  Fleet 

Vehicle  fleet  for  this  vehicle 

5  Attrit  or  Damage  Day 

day 

Last  attrit  or  breakdown  day  for  this  vehicle,  if  any 

6  Replace  or  Repair  Day 

day 

Last  replacement  or  repair  day  for  this  vehicle,  if  any 

7  Computed  Course 

Current  course  direction  computed  for  the  current  date  and  time 

8  Computed  Latitude 

deg  min  H 

Current  latitude  computed  for  the  current  date  and  time 

9  Computed  Longitude 

deg  min  H 

Current  longitude  computed  for  the  current  date  and  time 

Figure  4-15.  Output  Data  Elements  for  the  Vehicle  Table 
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4.3  Transportation  Network  Data 

Figure  4-16  provides  an  overview  of  the  data  tables  and  relationships  for  representing  the  transportation 
network.  Once  a  global  network  is  established,  most  of  this  data  is  again  relatively  stable  for  different 
studies,  except  when  extending  to  intratheater  analyis  for  a  new  area  of  the  world,  or  when  running  at  very 
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Figure  4-16.  Data  Tables  and  Relationships  for  Transportation  Network 


high  level  of  detail  with  sub-networks  at  facilities. 
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4.3.1  Node 


A  Node  is  simply  a  location  in  GDAS,  with  a  latitude  and  longitude.  A  Node  may  represent  a  port  location 
with  facilities  (POE,POD,POI),  an  origin,  a  destination,  a  transshipment  point,  a  turning  point  or  waypoint, 
a  refueling  location,  a  canal  entrance  point,  a  staging  location,  an  assembly  point,  or  any  other  location. 


Field  Name 

Units 

Description 

1  Node  Name 

Node  name  corresponding  to  a  port,  transhipment  point,  origin, 
destination,  routing  point  etc. 

2  Node  Type 

Node  type  for  world  map  graphics  display 

3  Node  Latitude 

deg  min  H 

Node  latitude  in  dd  mm  H 

4  Node  Longitude 

deg  min  H 

Node  longitude  in  ddd  mm  H 

5  Geoloc  Code 

Node  geoloc  code,  if  any 

6  Theater 

Theater  that  the  node  is  located  in,  if  any 

7  Attrit  Probability  %% 

%% 

Discrete  probability  of  attrition  or  breakdown  when  departing  this  node 

8  Is  Node  Disabled? 

Yes  if  the  node  is  disabled,  otherwise  blank 

Figure  4-1 7.  Data  Elements  for  the  Node  Table 


4.3.2  Node  Link 

A  Node  Link  represents  a  transportation  link  from  one  node  to  another  on  which  transport  vehicles  can 
move.  Each  link  is  assigned  a  single  Transport  Mode,  so  that  several  links  may  exist  between  the  same  two 
nodes  for  different  transport  modes.  Data  about  the  link  include  the  From  Node,  To  Node,  Transport  Mode, 
Link  Distance  (which  is  computed  as  a  great  circle  if  left  blank),  Added  Delay  Hours  (e.g.,  for  canal  or 
other  delays),  Speed  Change  (with  or  against  a  current  or  wind),  Speed  Limit,  etc.  The  network  links  are 
connected  to  form  a  multi-nodal  route  path  in  GDAS  in  the  routing  algorithm. 


Field  Name 

Units 

Description 

1  From  Node 

From  node  name 

2  To  Node 

To  node  name 

3  Transport  Mode 

Transport  mode  for  this  link  (only  one  link  is  permitted  for  each  mode; 
multiple  links  can  be  created  by  adding  nodes) 

4  Is  Link  Disabled? 

Yes  if  the  link  is  available,  blank  otherwise 

5  Link  Dist 

nmi 

Computed  link  distance  in  miles  based  on  great  circle  (can  also  be  set  by 
the  user,  but  will  be  recalculated  as  the  great  circle  distance  if  less  than 
the  great  circle  distance) 

6  Added  Delay  Hours 

hr 

Delay  time  on  this  link  in  hours 

7  Speed  Change 

knot 

Speed  change  (positive  for  increase,  negative  for  decrease)  which  is 
added  to  the  transport  speed  on  this  link  (for  sealift  an  approximate 
calculation  is  to  get  an  equivalent  distance  change) 

8  Speed  Limit 

knot 

Speed  limit  which  constrains  the  allowable  transport  speed  on  this  link 
(for  sealift  an  approximated  distance  change  is  computed) 

9  Link  Rating 

Link  rating  for  the  size  of  vehicles  which  are  permitted  through  this  link 
relative  to  the  size  required  for  a  given  Route  Type 

10  Attrit  Daily  Rate  %% 

%%/day 

Attrition  or  breakdown  rate  on  this  link  for  exposure-based  attrition 

Figure  4-18.  Data  Elements  for  the  Node  Link  Table  (NodeLink). 


4.3.3  Theater 

A  Theater  represents  a  subset  of  nodes  classified  by  area  of  the  world.  A  Theater  is  assigned  to  each  Node 
primarily  for  reporting  purposes,  although  theater  is  also  used  to  specify  resupply  generation  factors  and 
determine  if  convoying  is  applicable. 


GDAS  Algorithm  Description 


4-13 


Database  Tables 


Field  Name 

Units 

Description 

1  Theater 

Theater  name 

2  Mobilization  M  Day 

day  (hr) 

Theater  M  day  or  begin  mobilization  day  relative  to  global  day  0 _ 

3  Deployment  C  Day 

day  (hr) 

Theater  C  day  or  commence  deployment  day  relative  to  global  day  0 

4  Combat  D  Day 

day  (hr) 

Theater  D  day  on  which  casualties  and  attrition  begin,  relative  to  global  day  0 

5  Earliest  Depart  Day 

day  (hr) 

Earliest  day  that  a  vehicle  can  leave  after  exiting  the  POE  facility  before 
traveling  towards  this  theater  (cargo  can  be  preloaded  and  the  facility  exited) 

6  Start  Planning  Day 

day  (hr) 

Day  on  which  requirements  can  first  start  being  considered  for  scheduling  to  this 
theater  . .  _  . . . . . . 

Figure  4-19.  Data  Elements  for  the  Theater  Table 


4.3.4  Facility 

A  Facility  represents  a  loading  or  unloading  capability  at  a  node,  for  example  a  seaport,  airport,  truck 
terminal  or  rail  terminal.  A  node  with  facilities  normally  has  more  than  one,  such  as  both  a  truck  terminal 
and  a  seaport,  to  permit  transfer  from  one  mode  to  another.  All  transfers  of  cargo  onto  a  vehicle  or  off  of  a 
vehicle  must  occur  at  a  facility.  Origins  and  destinations  of  movement  requirements  must  also  have 
facilities  (this  is  checked  by  GDAS).  A  Facility  has  a  Facility  Type,  which  affects  which  vehicle  types  and 
cargo  types  are  compatible  with  the  Facility  and  what  the  load/unload  rates  are. 


Field  Name 

Units 

Description 

INode 

Node  with  one  or  more  facilities  _ 

2  Facility  Name 

Facility  name  at  this  node 

3  Facility  Type 

Facility  type  for  this  facility 

4  Max  Vehicles  Per 

veh/hr 

Number  of  combined  vehicle  arrivals  and  departures  which  can  be  handled  per 

Hour 

hour  in  this  facility  during  its  hours  of  operation 

5  Max  Parking 

veh 

Maximum  number  of  “standard”  vehicles  permitted  in  the  facility  at  die  same 
time,  e.g.  working  MOG  for  airlift  or  number  of  berths  for  sealift  (vehicle  types 
are  weighted  by  an  effective  factor  to  convert  to  a  standard  vehicle)  (model 
scales  by  100  to  %) 

6  Operating  Hours/Day 

hr/day 

Operating  hours  per  day  that  the  facility  is  open 

7  Facility  Length 

ft 

Maximum  length  available  (e.g.,  runway  length  for  air,  berth  length  for  sea) 

8  Facility  Width 

ft '7*-' 

Maximum  width  available  (e.g.,  runway  width  for  air,  berth  beam  for  sea) 

9  Facility  Dimension 

varies 

Maximum  vehicle  dimension  allowed  in  the  facility,  a  user-definable  criterion, 
such  as  draft  for  sealift 

16  Facility  Rating 

varies 

Facility  rating  whichlimits  die  maximum  allowable  vehicle  rating,  based  on  a 
user-definable  critieria  (e.g.,  load  classification  number  for  air,  boom  capacity  or 
sea)  _  . .  _  _ _ _ _ 

Figure  4-20.  Data  Elements  for  the  Facility  Table 


4.3.5  Facility  Type 

A  Facility  Type  in  the  FacType  table  represents  a  kind  of  facility  that  can  handle  certain  kinds  of  cargo  and 
vehicle  types.  Each  Facility  Type  has  a  single  Transport  Mode  for  which  it  applies,  and  each  Facility  at  a 
node  must  be  listed  with  a  single  Facility  Type.  The  Facility  Type  affects  the  allowable  Vehicle  Types 
which  can  enter  the  Facility  and  it  affects  die  load/unload  rates  for  different  Cargo  Types. 

4.3.6  Vehicle/Facility  Type 

The  Vehicle/Facility  Type  records  in  the  VFacType  table  specify  which  Vehicle  Types  are  compatible  with 
which  Facility  Types.  The  records  and  key  fields  are  entered  automatically  by  GDAS  for  all  matching 
modes.  In  addition,  setup  and  shutdown  delays  can  be  specified  for  vehicles  entering  the  facility  types. 
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Field  Name 

Units 

Description 

1  Vehicle  Type 

Vehicletype  _  _ _  _ _ _  _ _ 

2  Facility  Type 

Facility  type  with  matching  mode  _ _ _ _ 

3  Is  Vehicle  Excluded? 

T/F 

Checked  or  True  if  the  vehicle  type  is  excluded  from  loading  and  unloading 
cargo  at  this  facility  type,  otherwise  False  (vehicle  may  still  refuel  unless 

prevented  by  Is  Refuel  Excluded?  field)  _ _ _ _ 

Fixed  setup  or  entrance  delay  time  for  this  vehicle  type  while  occupying  this 
facility  type  (the  vehicle  takes  parking  space  and  the  facility  must  be  open 
during  setup;  setup  delays  vehicle  and  cargo  loading/unloading) 

4  Setup  Delay 

hr 

5  Shutdown  Delay 

hr 

Fixed  shutdown  or  exit  time  for  this  vehicle  type  while  occupying  this  facility 
type  (the  vehicle  takes  parking  space  and  the  facility  must  be  open  during 
shutdown;  shutdown  delays  vehicle  but  not  cargo  loading  or  unloading) _ 

6  Facility  Visit  Penalty 

$/visit 

Penalty  for  multi-facility  visits  on  a  single  trip,  used  in  the  scheduling 
algorithm  (the  first  POE  and  POD  facilities  on  a  new  trip  are  not  penalized) 

Figure  4-21.  Data  Elements  for  the  Vehicle  Facility  Type  Table  (VFacType). 


4.3.7  Vehicle/Facility  Cargo  Dimension 

The  Vehicle/Facility  Cargo  Dimension  table,  VFacDim,  lets  you  set  cargo  dimension  limits  that  constrain 
the  capabilities  of  different  Vehicle  Types  for  loading/unloading  cargo  at  the  specified  Facility  Types.  This 
table  is  useful  only  if  the  cargo  measures  include  dimension  limits  such  as  Max  Height  or  Max  Length  and 
you  wish  to  set  limits  on  what  dimension  limits  are  compatible  with  different  Vehicle  Types  and  Facility 
Types. 


Field  Name 

Units 

Description 

I  Vehicle  Type 

Vehicle  type  with  cargo  dimension  constraint 

2  Facility  Type 

Matching  facility  type  with  cargo  dimension  constraint 

3  Max  Dimension 
Measure 

Cargo  dimension  constraint  measure  (Item  Height  Ft,  Item  Weight  Ston,  etc.) 

4  Max  Cargo 
Dimension 

ft,ston,  <•■ 
mton,  etc. 

Cargo  dimension  limit  to  exclude  cargo  that  is  too  big  from  loading  on  this 
vehicle  type  at  this  facility  type 

Figure  4-22.  Data  Elements  for  the  Vehicle  Facility  Type  Dimension  Table  (VFacDim). 


4.3.8  Facility  Capacity 

Each  Facility  at  a  Node  can  be  constrained  by  one  or  more  throughput  and  storage  capacities  as  specified  in 
the  Facility  Capacity  table,  FacCap.  Each  Facility  Capacity  record  is  entered  for  user-specified  throughput 
measures  such  as  Mton/Hr,  SqFt/Hr,  or  Ston/Hr,  or  storage  measures  such  as  SqFt  Storage.  Multiple 
constraint  measures  and  capacities  can  be  entered  and  enforced  simultaneously  for  a  single  Facility.  Note 
that  different  kinds  of  cargo  can  utilitize  facility  capacity  at  different  rates  for  different  Vehicle  Types  (see 
the  LoadRate  table). 


Field  Name 

Units 

Description 

1  Facility  Node 

Node  with  one  or  more  facilities 

2  Facility  Name 

Facility  name  at  this  node 

3  Facility  Capacity  Measure 

Cargo  storage  or  throughput  handling  capacity  measure  for  this  facility 

4  Facility  Capacity 

Q/hr 

Hourly  rate  or  total  storage  cargo  handling  capacity  for  this  measure 
and  facility  at  the  node 

Figure  4-23.  Data  Elements  for  the  Facility  Capacity  Table  (FacCap). 


4.3.9  Node  Capacity 

Similar  to  Facility  Capacity,  each  Node  can  be  constrained  by  one  or  more  throughput  and  storage 
capacities  as  specified  in  the  Node  Capacity  table,  NodeCap.  The  difference  between  a  Node  Capacity  and 
a  Facility  Capacity  is  that  the  Node  Capacity  is  a  shared  constraint  applied  to  all  facilities  at  the  Node, 
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whereas  the  Facility  Capacity  applies  to  a  single  Facility  only.  Thus,  the  Node  Capacity  is  useful  when 
shared  resources  (such  as  stevedores  or  forklifts)  are  used  for  loading/unloading  across  multiple  facilities, 
possibly  across  several  modes.  Each  Node  Capacity  record  is  entered  for  user-specified  throughput 
measures  such  as  Mton/Hr,  SqFt/Hr,  or  Ston/Hr,  or  storage  measures  such  as  SqFt  Storage.  Multiple 
constraint  measures  and  capacities  can  be  entered  and  enforced  simultaneously  for  a  single  Node. 


Field  Name 

Units 

Description 

1  Node  Name 

Node  having  throughput  or  storage  limits 

2  Node  Capacity  Measure 

Unit  of  measure  for  overall  cargo  handling  capacity  at  the  node 

3  Total  Node  Capacity 

Q/hr 

Hourly  throughput  rate  or  total  storage  cargo  handling  capacity  at  the  node 
for  all  facilities  combined 

Figure  4-24.  Data  Elements  for  the  Node  Capacity  Table  (NodeCap) 
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4.4  Movement  Requirements  Data 

Figure  4-25  provides  an  overview  of  the  data  tables  and  relationships  for  representing  movement 
requirements.  Again,  most  of  die  data  is  static  “type”  data  to  set  up  the  basic  cargo  categories  and  units  of 
measure.  The  primary  tables  that  are  filled  in  for  a  given  study  are  the  movement  requirements  (Require), 
their  quantities  (ReqQuan),  and  any  required  nodes  (ReqNode). 


ReqClass 

Requirement 

Class 


BasMeas 

Basic  Measure 


Measure 


ReqType 

Requirement 

Type 


CargClas 

Cargo  Class 


ClasMeas 

Cargo  Class 
Measure 


MajUnit 

Major  Unit 


CargoCat 

Cargo 

Category 


1  1 - J 

— < 

Require 

Movement 

Requirement 

CatMeas 
s  Derived  Categ 
Measure 


ReqQuan 

Requirement 

Quantity 


ReqNode 

Required 

Node 


ReqMode 

Require/Mode 

Exclusion 


Figure  4-25.  Data  Tables  and  Relations  for  Movement  Requirements 
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4.4.1  Movement  Requirement 

The  Movement  Requirement  provides  die  basic  data  about  what  is  to  be  moved  where  and  when.  Each 
Movement  Requirement  is  listed  in  the  Require  table  with  a  Requirement  Id,  an  Origin  node,  a  Destination 
node,  a  Ready  to  Load  Day  (RLD),  and  a  Required  Delivery  Day  (RDD).  A  single  Movement  Requirement 
can  constitute  a  package  of  multiple  items  with  different  cargo  categories. 


Field  Name 

Units 

Description 

1  Requirement  Id 

Movement  requirement  or  package  id 

2  Major  Unit 

Major  unit  associated  with  this  movement  requirement 

3  Origin 

Starting  origin  of  the  requirement 

4  Destination 

Final  destination  of  the  requirement 

5  RLD 

day 

Ready  to  load  day  or  earliest  day  the  requirement  is  available  at  its  origin 

6  RDD 

day 

Required  delivery  day  of  the  packaged  requirement  at  its  destination  including 
time  for  assembly 

7EDD 

day 

Earliest  allowed  delivery  day  of  the  requirement  at  its  destination  prior  to 
assembly 

8  Computed  Closure 

Day 

day 

Closure  day  for  the  requirement  based  on  the  closure  minimum  %  requirement 
specified  in  the  ReqType  table 

9  Priority  Order 

Relative  priority  order  for  this  requirement  as  a  secondary  sort  after  the  Target 

Lift  Date  (one  means  first  priority  in  assigning  lift  assets,  blank  defaults  to  the 
priority  order  of  the  requirement  type) 

Figure  4-26.  Data  Elements  for  the  Movement  Requirement  Table  (Require). 


4.4.2  Cargo  Category 

A  Cargo  Category  provides  the  most  detailed  representation  in  GDAS  of  the  kind  of  cargo  to  be 
transported.  In  many  cases,  the  GDAS  Cargo  Category  corresponds  to  JOPES  three-digit  cargo  category 
codes,  perhaps  with  the  addition  of  some  cargo  categories  for  higher  resolution  in  intratheater  studies.  A 
single  Movement  Requirement  may  incorporate  multiple  cargo  categories  as  part  of  a  unit  movement 
package  from  origin  to  destination.  Each  Cargo  Category  uses  a  set  of  quantity  measures  (Mton,  Ston, 

SqFt,  Cbbls,  etc.)  that  are  applicable  based  on  the  Cargo  Class  as  set  up  in  the  ClasMeas  table. 

The  CargoCat  table  has  a  new  field  called  “Discrete  Load  Increment”.  This  field  is  used  to  specify  a 
smallest  increment  of  basic  quantity  size,  below  which  the  cargo  cannot  be  split.  For  example  if  some 
tracked  vehicle  category  has  no  vehicle  which  weighs  less  than  10  short  tons,  then  when  you  place  a  10  in 
this  field,  no  cargo  of  this  category  will  be  split  into  any  size  other  than  a  multiple  of  10.  If  the  original 
requirement  quantity  is  not  an  even  multiple  of  10,  there  may  still  be  a  final  split  cargo  that  cannot  be  a 
multiple  of  10,  but  when  GDAS  subdivides  any  quantity  it  will  create  a  quantity  which  is  a  multiple  of  10. 
The  Discrete  Load  Increment  is  also  honored  when  GDAS  splits  cargo  among  compartments  in  a  multi¬ 
compartment  vehicle.  Thus,  each  compartment  will  hold  a  quantity  that  is  an  even  multiple  of  the  the 
discrete  load  increment,  except  perhaps  the  last  cargo  assigned  if  die  original  requirement  quantity  does  not 
start  out  as  an  even  multiple. 

Each  Cargo  Category  can  also  have  special  ammunition  handling,  which  requires  that  ammo  be  last-on, 
first-off  in  routing. 
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Field  Name 

Units 

Description 

1  Cargo  Category 

2  Cargo  Class 

- . - 

Cargo  category  which  describes  the  kind  of  cargo  being  transported 

Cargo  class  (Dry,  Pax,T?OL)  which  defines  dimensional  measures  for  this 
cargo  category 

3  Category  Code 

Four  position  JOPES  cargo  category  code  including  heavy  lift  code 
(AO=vehicle  NAT,  B0=NSDA  NAT,  B1=NSDA  outsize,  B2C=NSDA 
oversize  noncont,  etc.) 

4  Discrete  Load  Increment 

Q 

Discrete  size  increment  for  loading  Sis  cargo,  expressed  in  the  basic  unit 
of  measure;  if  specified,  a  split  cargo  must  be  an  integer  multiple  of  the 
size  increment 

5  Configuration  at  Origin 

T/F 

Starting  cargo  configuration  at  the  origin  for  this  cargo  category 

6  Is  Ammunition? 

Checked  or  True  if  the  cargo  category  is  treated  as  hazardous  ammunition 
in  route  sequence,  i.e.  it  is  constrained  to  be  last  on  and  first  off  in  multi- 
port  routes,  otherwise  False 

7  Description 

Description  of  the  cargo  category 

Figure  4-27.  Data  Elements  for  the  Cargo  Category  Table  (CargoCat). 


4.4.3  Cargo  Class 

The  Cargo  Class  table,  CargClas,  is  an  abstract  table  that  is  used  to  identify  what  units  of  measure  apply  for 
the  different  cargo  categories.  The  typical  Cargo  Classes  in  GDAS  are  as  follows: 

•  “Dry”,  which  uses  Ston,  Mton,  and  SqFt  measures 

•  “Pax”,  which  uses  Pax  (the  number  of  passengers)  as  the  only  measure 

•  “POL”,  with  Cbbls  as  the  only  measure 

•  “TEU”,  with  Ston,  Mton,  SqFt,  and  TEU  as  measures. 


Of  course,  these  Cargo  Classes  can  be  extended  or  revised  in  the  database  for  a  particular  study  application. 
Note  that  in  the  figure,  the  notation  “Q”  refers  to  the  Basic  Quantity  Measure  specified  in  field  2. 


Field  Name 

Units 

Description 

1  Cargo  Class 

Cargo  class  (Dry,  Pax,  POL)  which  defines  dimensional  measures 
for  cargo 

2  Basic  Quantity  Measure 

Basic  unit  of  measure  for  reporting  quantity  of  this  cargo  class  (ston, 
pax,  cbbl) 

3  Pounds  Per  Basic  Quantity 

lbs/Q 

Pounds  per  unit  basic  quantity  in  the  basic  unit  of  measure,  used  for 
conversion  to  accumulate  ston  weight  totals  for  vehicle  loading  or 
facility  throughput 

4  Has  Accompanying  Pounds? 

lbs/Q 

Yes  if  theater-dependent  accompanying  pounds  per  unit  basic 
quantity  are  obtained  from  the  THTRREQ  table  rather  than  a 
conversion  factor  (otherwise  Pounds  Per  Basic  Quantity  field  is 
used) 

5  Is  Pax? 

Yes  if  the  cargo  class  represents  passengers,  used  to  compute  closure 
based  on  the  MAJUNIT  %  closure  criteria 

Figure  4-28.  Data  Elements  for  the  Generic  Cargo  Class  Table  (CargClas),  where  Q  is  the  Basic  Quantity  Measure. 


4.4.4  Cargo  Class  Measure 

The  Cargo  Class  Measure  table,  ClasMeas,  lists  which  measures  apply  to  each  Cargo  Class.  For  example, 
“Dry”  movement  requirements  utilize  all  three  units  of  measure  for  loading  of  cargo  onto  vehicles,  so  that 
the  movement  requirement  quantities  are  listed  using  all  three  three  measures.  The  Cargo  Class  Measures 
can  be  changed  to  configure  GDAS  for  different  levels  of  detail,  ranging  from  highly  aggregated  Ston 
flows  down  to  detailed  line  items  with  Max  Height,  Max  Length,  and  Max  Width  as  well  as  area,  volume, 
and  weight. 
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Once  the  ClasMeas  table  is  established,  GDAS  automatically  derives  the  CatMeas  table,  which  lists  the 
valid  quantity  measures  for  each  Cargo  Category.  This  serves  as  a  reference  lookup  table  in  editing  the 
Movement  Requirement  Quantities  in  ReqQuan  (described  in  Section  4.4.6). 


I  Field  Name 

Description 

Cargo  class  (Dry,  Pax,  POL)  which  defines  dimensional  measures  for  cargo 

1  2  Cargo  Measure 

Type  of  measure  used  for  specifying  quantity  or  dimension  of  cargos  in  this  cargo  class 

Figure  4-29.  Data  Elements  for  the  Cargo  Class  Measure  Table  (ClasMeas). 


4.4.5  Basic  Quantity  Measure 

Each  Cargo  Class  is  assigned  a  special  measure  that  is  the  Basic  Quantity  Measure,  as  shown  earlier  in 
Figure  4-28.  The  “Sample”  database  scenario  assigns  Ston  as  the  basic  measure  for  the  Dry  Cargo  Class, 
Cbbl  for  POL  Cargo  Class,  and  Pax  for  Pax  Cargo  Class.  Since  the  quantity  measure  varies,  it  is  listed 
generically  as  Q  in  the  Dictionary  units  column.  The  Basic  Quantity  Measure  is  used  in  the  model  to 
specify  the  discrete  cargo  load  quantities  on  vehicles  and  is  also  used  for  most  reports.  In  addition,  the 
Basic  Quantity  Measure  represents  the  smallest  discrete  size  allowed  for  cargo  splits.  This  property  can  be 
used  to  advantage  to  represent  discrete  cargo  increments  such  as  Pax,  Containers,  or  even  discrete  items 
such  as  Tanks  by  adding  the  appropriate  Basic  Quantity  Measure. 

4.4.6  Movement  Requirement  Quantities 

Each  Movement  Requirement  has  associated  with  it  one  or  more  Quantity  records  in  the  ReqQuan  table. 
These  Quantities  specify  both  the  Cargo  Categories  and  the  matching  units  of  measure.  For  example,  a 
single  unit  movement  may  have  a  Pax  cargo  category  measured  in  Pax  only,  as  well  as  several  Dry  cargo 
categories  (containerizable  breakbulk,  non-containerizable  outsize,  etc)  each  measured  in  Ston,  Mton,  and 
SqFt  quantities. 


Field  Name 

Units 

Description 

1  Requirement  Id 

Requirement  identifier  for  the  cargo 

2  Cargo  Category 

Cargo  category,  e.g.  oversize  containerizable  vehicle,  Pax,  NEO,  Medivac,  etc. 

3  Cargo  Measure 

Dimensional  measure  for  this  requirement  and  cargo  category 

4  Quantity 

Q 

Requirement  category  quantity  or  dimension  in  this  unit  of  measure 

Figure  4-30.  Data  Elements  for  the  Requirement  Quantity  Table  (ReqQuan). 


4.4.7  Requirement  Class,  Requirement  Type,  Major  Unit,  Service 

Several  levels  of  aggregation  are  available  to  represent  the  type  of  movement  requirements,  primarily  for 
reporting  totals.  Each  Movement  Requirement  has  a  Major  Unit  in  the  MajUnit  table,  which  specifies  the 
functional  type  or  purpose  of  the  movement  (e.g.,  a  TPSN  in  the  Army  environment,  or  some  other  study- 
specific  identifier)  The  Major  Unit  is  used  in  the  reporting  and  charting  tools  to  display  total  delivery 
profiles  with  required  versus  delivered  quantities  by  day.  The  Major  Unit  is  also  used  for  assigning 
Measure  of  Effectiveness  in  certain  output  reports. 
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Field  Name 

Units 

Description 

1  Major  Unit 

Major  unit  name  for  analysis  of  requirement  closures  and  measures  of 
effectiveness 

2  Major  Unit  TPSN 

Major  unit  Troop  Program  Sequence  Number  (TPSN)  or  other  user- 
defined  identifier  for  the  major  unit 

3  Requirement  Type 

Requirement  type  for  this  major  unit 

4  Major  Unit  MOE 

Measure  of  effectiveness  (MOE)  rating  for  this  major  unit  (e.g.,  brigade 
count  or  combat  power)  as  defined  by  the  analyst  to  compute  cumulative 
MOE  delivery 

5  Computed  Closure  Day 

day 

Closure  day  for  the  major  unit  based  on  both  the  Pax  and  cargo  closure 
minimum  %  specified  in  the  ReqType  table 

6  Closure  Required  Cargo  % 

% 

Minimum  percent  of  the  cargo  which  must  be  delivered  in  order  to 
calculate  unit  closure  (if  the  %  is  never  attained,  closure  is  based  on  the 
last  portion  delivered) 

7  Closure  Required  PAX  % 

% 

Minimum  percent  of  the  passengers  which  must  be  delivered  in  order  to 
calculate  unit  closure  (if  the  %  is  never  attained,  closure  is  based  on  the 
last  portion  delivered) 

8  Major  Unit  Description 

Major  unit  description 

Figure  4-31.  Data  Elements  for  the  Major  Unit  Table  (MajUnit). 


At  a  higher  level  of  aggregation,  each  Major  Unit  is  assigned  a  Requirement  Type  in  the  ReqType  table. 
The  Requirement  Types  are  used  to  set  scheduling  priorities  and  penalties  for  the  model. 
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Field  Name 

Units 

Description 

1  Requirement  Type 

2  Requirement  Class 

-  . . 

Requirement  type  or  unit  type  _ _ _ _ 

Aggregated  requirement  class  for  calculating  summary  cargo  delivery  versus 
required  totals  for  reports  _  _  _ 

3  Service 

Service  for  this  requirement  type  or  unit  type  _  _ _ 

4  Planning  Horizon  Days 

day  (hr) 

Planning  or  look-ahead  horizon  in  days  for  scheduling  cargos  of  this 
requirement  type  prior  to  their  target  lift  date 

5  Assembly  Delay  Days 

day  (hr) 

Additional  assembly  delay  days  needed  after  delivery  at  the  destination  used  to 
calculate  closure  and  lateness  relative  to  the  RDD 

6  RLD  Packaging  Range 

day  (hr) 

Packaging  range  for  merging  movements  with  similar  Ready  to  Load  Dates 
(RLDs) 

7  RDD  Packaging  Range 

day  (hr) 

Packaging  range  for  merging  movements  with  similar  Required  Delivery  Dates 
(RDDs) 

8  RDD  Tolerance 

day  (hr) 

Days  tolerance  for  lateness  at  the  destination  relative  to  the  RDD  before  mode 
planning  increases  delivery  cost  to  reduce  lateness 

9  Max  Days  Late 

day  (hr) 

Days  late  relative  to  the  target  delivery  date  beyond  which  a  cargo  is  rejected 
in  scheduling  and  is  reported  with  rejection  reasons,  even  if  the  penalty  is 
acceptable  _  _ 

10  Cargo  Lateness  Penalty 

.01$/Q-day 

Penalty  for  cargo  ton-days  of  lateness  (as  compared  with  vehicle  usage 
penalties)  in  the  scheduling  algorithm 

11  Penalty /Benefit  Cut-off 

$/$ 

Cost  cut  off  level  above  which  a  potential  cargo  assignment  is  rejected  early  in 
the  multi-port  scheduling  algorithm  (blank  or  a  large  value  means  no  cutoff) 

12  Early  Assignment 

Level 

$/F 

Threshold  penalty/benefit  level  below  which  a  potential  cargo/ship  assignment 
is  accepted  immediately  in  the  multi-port  scheduling  algorithm  (a  large  value 
reduces  run  time  but  may  make  a  selection  before  costing  a  preferred  vehicle) 

1 3  Regeneration  Delay 
Days 

day  (hir) 

Nonzero  delay  days  to  regene”rate  attritted  cargo  for  this  requirement;  cargo  is 
regenerated  with  the  same  data  as  the  original  movement  (blank  means  no 
regeneration) 

U  Default  Priority  Order 

Default  priority  order  for  this  requirement  type  if  not  specified  for  a  given 
requirement  (1  is  the  earliest  priority  order;  blank  is  treated  as  no  priority  or  as 
99) 

Minimum  %  split  of  a  single  cargo  (i.e.  requirement+category)  for  assigning  to 
a  separate  non-airlift  trip  (not  used  for  airlift;  100%  prevents  any  non-airlift 
splitting;  this  is  separate  from  the  Minimum  Cargo  Load  %  and  Minimum 
Vehicle  Load  %  in  Param) 

15  Minimum  Cargo  Load 
% 

% 

16  Integrity  Benefit 

day  (hr) 

Wait  days  benefit  indicating  a  preference  for  loading  identical  Requirement 

Id’s  onto  the  same  vehicle  trip  .  _  _ _  _ _ 

17  Is  Resupply? 

True  or  checked  if  this  requirement  type  is  dynamically  ordered  by  other 

requirements  in  the  theater,  when  dynamic  resupply  is  being  modeled  _ _ 

Figure  4-32.  Data  Elements  for  the  Requirement  Type  Table  (ReqType). 


At  yet  a  higher  level  of  aggregation,  each  Requirement  Type  is  assigned  a  general  Requirement  Class  (e.g., 
“Unit”  versus  “Resupply”)  and  a  Service.  The  Requirement  Class  is  used  solely  for  summary  reports  and 
charts,  such  as  total  “Unit”  requirements  delivered  by  day.  In  addition,  the  Requirement  Type  is  assigned  a 
unique  Service  (Army,  Navy,  USMC,  Air  Force,  etc.),  again  for  reporting  purposes. 

4.4.8  Required  Node,  Require/Mode  Exclusion 

The  Required  Node  records  in  the  ReqNode  table  are  used  to  pre-assign  intermediate  POEs  and  PODs  for  a 
Movement  Requirement  For  a  given  study,  it  may  be  necessary  to  specify  the  POEs  and  PODs  based  on 
external  study  inputs  or  staging  requirements,  rather  than  allowing  the  model  to  select  POEs  and  PODs 
from  Origin  to  Destination  using  the  GDAS  mode  planning  algorithm. 
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Field  Name 

Units 

Description 

1  Requirement  Id 

2  Cargo  Class 

3  LAD 

day  (Shir) 

Movement  requirement  identifier  with  intermediate  ports  or  staging 

Cargo  class  for  which  the  required  node  applies 

Latest  arrival  day  at  this  required  port  node  (the  LAD  is  used  to  determine the 
order  in  which  required  nodes  are  visited) 

4EAD 

day  (hr) 

Earliest  arrival  day  at  this  required  port  node,  if  any 

5  Required  Node 

Required  intermediate  POE/POD  node  or  port  for  this  movement  requirement 

6  Required  Mode  to  Node 

7  Required  Config  to 

Node 

8  Stage  Name 

9  Description 

- - - 

Required  transport  mode  specified  for  delivery  to  the  intermediate  node,  if  any 
(blank  permits  the  use  of  any  mode  for  delivery) 

Required  configuration  specified  for  delivery  to  the  TntermedTatelnode”  if  any 
(blank  permits  the  use  of  any  configuration) 

Staging  deployment  name  if  multiple  requirements  are  staged  together  at  this 
node  (the  STAGE  record  must  have  the  same  node  as  in  REQNODE) 
Description  of  this  intermediate  node,  e.g.  consolidation,  container  stuffing, 
mode  change,  re-configuration,  combat  loading,  etc. 

Figure  4-33.  Data  Elements  for  the  Required  Node  Table  (ReqNode). 


Similarly,  the  ReqMode  table  lists  excluded  modes  for  different  Movement  Requirements  and  Cargo 
Classes.  Typically,  mode  exclusions  depend  on  the  Cargo  Class,  e.g.  Dry  may  exclude  Airlift  modes 
(traveling  on  Road,  Rail,  and  Sealift)  whereas  Pax  may  exclude  Sealift  (traveling  on  Road,  Rail,  and 
Airlift). 


Field  Name 

Units 

Description 

1  Requirement  Id 

Movement  requirement  having  a  mode  exclusion 

2  Cargo  Class 

Cargo  class  for  which  the  mode  exclusion  applies 

3  Excluded  Mode 

Excluded  mode  for  this  requirement  and  cargo  class 

Figure  4-34.  Data  Elements  for  the  Requirement  Mode  Exclusion  Table  (ReqMode). 
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4.5  Loading  Characteristics 

Figure  4-35  provides  an  overview  of  the  data  tables  and  relationships  for  loading  characteristics.  Most  of 
these  tables  have  been  discussed  above;  only  the  five  lower  right  tables  are  new.  All  of  this  data  is  generic 
“type”  data  that  typically  does  not  change  for  different  studies. 


Mode 

Transport 

Mode 
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CptType 

Compartment 

Type 


RoutType 

Route  Type 


CatMode 

Category 

Mode 
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CargType 
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Stowage 
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FacType 
Facility  Type 


VFacType 
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-d  Load  Rate 


■< 


StowFact 

Stowage 
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Figure  4-35.  Data  Tables  and  Relationships  for  Loading  Characteristics 

4.5.1  Cargo  Type 

A  Cargo  Type  in  the  CargType  table  represents  an  aggregation  of  the  Cargo  Category  for  a  specific 
Transport  Mode.  The  Cargo  Type  is  sufficient  to  determine  the  loading  characteristics  for  a  given  Mode. 
For  the  Airlift  mode,  as  an  example,  numerous  Cargo  Category  records  can  be  mapped  to  just  four  Cargo 
Types  consisting  of  Bulk,  Oversize,  Outsize,  and  Pax.  For  the  Airlift  mode,  only  these  Cargo  Types  are 
relevant  in  determining  the  loading  characteristics.  By  expressing  the  loading  characteristics  in  terms  of 
Cargo  Types  rather  than  the  more  detailed  Cargo  Categories,  far  fewer  stow  factors,  load/unload  rates,  and 
compartment  matching  rules  need  be  entered. 

Each  Cargo  Type  is  assigned  a  Cargo  Class  to  identify  which  quantity  measures  are  applicable  to  the  Cargo 
Type. 
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Field  Name 

Description 

1  Cargo  Type 

Mode-specific  cargo  type  which  groups  cargo  categories  for  a  given  transport 
mode  in  order  to  define  stow  factors,  load  rates,  and  load  compatibility  for  vehicle 
compartments 

2  Cargo  Class 

Cargo  class  (Dry,  Pax,  POL)  for  this  cargo  type,  which  defines  which  dimensional 
measures  are  applicable  for  this  cargo  type 

3  Transport  Mode 

Transport  mode  associated  with  this  mode-specific  cargo  type 

4  Cargo  Type  Description 

Description  of  the  mode-specific  cargo  type 

Figure  4-36.  Data  Elements  for  the  Cargo  Type  Table  (CargType). 


4.5.2  Category  Mode 

The  Category  Mode  table,  CatMode,  specifies  how  the  Cargo  Categories  map  to  Cargo  Types  for  each 
Transport  Mode.  The  key  fields  and  records  are  pre-computed  by  GDAS;  the  user  need  enter  only  the 
matching  Cargo  Type  if  the  Cargo  Category  can  be  transported  by  a  particular  Transport  Mode  for  a 
particular  Cargo  Configuration.  Some  Cargo  Categories  cannot  be  transported  by  some  modes,  for  example 
Non- Air-Transportable  (NAT)  on  Airlift. 


_ Field  Name 

1  Transport  Mode 

2  Cargo  Category 

3  Cargo  Configuration 

4  Cargo  Type 


Units 


Description 


Transport  mode  _ _  .  _ _ _ _ _ _ _ _ _ 

Cargo  category  which  describes  the  kind  of  cargo  being  transported 

Cargo  configuration  status  _  _  _  _ _ 

Cargo  type  used  to  represent  this  cargo  category  and  configuration  for  the 


Figure  4-37.  Data  Elements  for  the  Category  Mode  Table  (CatMode). 


4.5.3  Stow  Penalties,  Stow  Factors 

The  StowPen  table  specifies  which  Compartment  Types  can  load  which  Cargo  Types.  Its  records  are  also 
pre-generated  by  GDAS,  and  only  the  compatibility  setting  and  stow  penalties  need  be  entered. 


1  Field  Name 

Units 

Description 

Vehicle  compartment  type 

2  Cargo  Type 

Cargo  type  with  matching  transport  mode  for  this  compartment 

3  Is  Stow  Excluded? 

Yes  if  this  cargo  type  is  excluded  from  stowage  in  this  compartment  type 

4  Stow  Penalty 

$/Q 

Stow  penalty  per  unit  basic  quantity  of  cargo  for  loading  into  this  vehicle 
compartment 

Figure  4-38.  Data  Elements  for  the  Stow  Penalty  Table  (StowPen). 


The  StowFact  table  stores  stow  factors  for  each  combination  of  Compartment  Type,  Compartment 
Measure,  and  Cargo  Type.  Different  capacity  measures  (Mton,  SqFt,  Ston,  etc.)  can  have  different  stow 
factors.  If  a  stow  factor  is  set  to  zero  or  blank  for  an  compartment  measure,  then  loading  is  excluded. 


Field  Name 

Units 

Description 

1  Compartment  Type 

Compartment  type 

2  Compartment  Measure 

Compartment  stowage  measure 

3  Cargo  Type 

Cargo  type  for  a  specific  transport  mode 

4  Stow  Factor  % 

Q/100C 

Stow  efficiency  in  percent  for  loading  the  cargo  type  in  the  compartment 
type  for  this  measure,  including  basic  quantity  conversion  if  the  cargo 
measures  don’t  match,  expressed  in  %  Q/C  (i.e.,  cargo  quantity  stowed 
per  100  compartment  capacity  measure) 

Figure  4-39.  Data  Elements  for  the  Stow  Factor  Table  (StowFact). 
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4.5.4  Load  Rates 

The  LoadRate  table  specifies  the  load  and  unload  rates  for  different  combinations  of  Vehicle  Type,  Cargo 
Type,  and  Facility  Type.  If  a  load  rate  or  unload  rate  is  set  to  zero  or  blank,  then  no  loading  is  permitted  for 
that  combination.  The  Load  Rate  table  also  specifies  the  scale  factor  for  utilization  of  facility  throughput 
capacity.  For  example,  some  Cargo  Types  (such  as  Container)  may  have  faster  unload  rates  as  well  as 
lower  throughput  utilization  for  suitable  Facility  Types  and  Vehicle  Types  (Container  ships). 


Field  Name 

Units 

Description 

1  Vehicle  Type 

Vehicle  type 

2  Facility  Type 

Facility  type  at  the  node 

3  Cargo  Type 

Cargo  type  for  the  transport  mode 

4  Hourly  Load  Rate 

Q/hr 

Hourly  load  rate  to  load  this  cargo  category  grouping  on  this  vehicle  type  at  this 
berth  type  expressed  in  the  cargo  basic  quantity  units  (loading  can  occur  only 
during  the  facility  open  hours) 

5  Hourly  Unload  Rate 

Q/hr 

Hourly  unload  rate  to  unload  this  cargo  category  grouping  on  this  vehicle  type 
at  this  berth  type  expressed  in  the  cargo  basic  quantity  units  (unloading  can 
occur  only  during  facility  open  hours) 

6  Cargo  Throughput 
Scaling 

% 

Cargo  throughput  scaling  which  adjusts  the  cargo’s  required  facility  and  node 
throughput  capacity  (100%  represents  standard  throughput  scaling,  0%  means 
the  cargo  does  not  affect  throughput  capacity  at  all,  50%  means  the  cargo 
consumes  half  throughput) 

Figure  4-40.  Data  Elements  for  the  Load  Rate  Table  (LoadRate). 


4.5.5  Exclusions 

The  Exclude  table  is  a  powerful  tool  to  exclude  specific  combinations  of  cargo  loading  based  on  multiple 
criteria..  Exclusions  within  the  Exclude  table  do  not  apply  to  routing  or  refueling  between  POEs  and  PODs, 
which  are  accomplished  through  the  use  of  the  RoutType  table.  The  Exclude  table  applies  to  loading  or 
unloading.  By  entering  a  Requirement  Type,  Vehicle  Fleet  and  Theater,  for  example,  all  loading  of  that 
Requirement  Type  on  that  Vehicle  Fleet  is  excluded  in  that  Theater. 

If  exclusions  can  be  specified  in  terms  of  stowage  constraints  or  cargo/vehicle/facility  type  matching,  they 
should  be  entered  using  zero  stow  factors  and/or  load  rates,  which  are  more  efficient  than  the  Exclude 
table.  For  example,  the  VFacType  table  can  exclude  a  vehicle  from  a  facility,  the  StowPen  table  can 
exclude  cargo  types  from  a  compartment,  and  the  LoadRate  table  can  exclude  combinations  of  Vehicle 
Type,  Facility  Type,  and  Cargo  Type.  The  Exclude  table  should  be  reserved  for  customized  exclusions  that 
cannot  be  represented  using  the  standard  “type”  data.  For  example,  the  Exclude  table  is  often  used  to 
prevent  selected  Vehicle  Fleets  from  loading  specific  Requirement  Types. 


Field  Name 

Description 

1  Exclusion  Label 

2  Node  Excluded  for 
Loading 

Label  for  a  user-defined  combination  of  factors  to  exclude  cargo  loading  at  POEs 
and  unloading  at  PODs  _ 

Excluded  node  for  loading  and  offloading,  if  any  (blank  if  not  applicable,  i.e.,  this 
exclusion  applies  to  all  nodes  and  is  independent  of  node) 

3  Facility  Type  Excluded 

Excluded  facility  type  for  loading  and  offloading,  if  any  (blank  if  not  applicable, 
i.e.  exclusion  record  applies  to  all  facility  types  or  is  independent  of  facility  type) 

4  Requirement  Type 
Excluded 

Excluded  requirement  type,  if  any  (blank  if  not  applicable) 

5  Vehicle  Type  Excluded 

Excluded  vehicle  type,  if  any  (blank  if  not  applicable) 

6  Planning  Fleet  Excluded 

Excluded  planning  fleet,  if  any  (blank  if  not  applicable) 

7  Theater  Excluded 

Excluded  theater,  if  any  (blank  if  not  applicable) 

8  Cargo  Category 

Excluded 

Excluded  cargo  category,  if  any  (blank  if  not  applicable) 

9  Mode  Excluded 

Excluded  transport  mode,  if  any  (blank  if  not  applicable) 

Figure  4-41.  Data  Elements  for  the  Exclude  Table. 
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4.6  Basic  Data  Table  Outputs 

The  primary  outputs  of  the  GDAS  simulation  model  are  the  vehicle  schedules  and  the  cargo  loads.  The 
basic  database  tables  which  store  this  data  are  shown  in  the  diagonal  boxes  with  solid  lines  in  Figure  4-42. 

Other  directly  related  input  tables  are  shown  in  boxes  with  dashed  lines.  The  basic  table  hierarchy  along  the 
diagonal  shows  that  each  Vehicle  can  make  multiple  Trips;  each  Trip  can  have  multiple  pickup  and 
delivery  Stops  at  node  facilities;  each  Stop  can  have  multiple  Cargos  for  loading  or  unloading;  and  each 
Cargo  can  have  multiple  Cargo  Loads  on  different  Vehicle  Compartments. 

Unlike  the  database  input  tables,  the  basic  model  output  data  tables  are  keyed  on  an  arbitrary  record 
number  identifier.  Thus  vehicles,  trips,  stops,  and  cargos  are  each  identified  by  a  unique  number. 
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CptType 

CargConf 
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Cargo 
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Type 

|  Configuration  j 
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Figure  4-42.  Basic  GDAS  Output  Tables  for  Vehicle  Schedules  and  Cargos 

4.6.1  Vehicle 

The  Vehicle  table  is  derived  from  the  VehFleet  table  and  is  an  output,  not  an  input.  The  GDAS  scheduling 
model  tracks  each  Vehicle  separately,  so  as  a  first  step  it  takes  each  VehFleet  record  and  “clones”  the 
individual  vehicles  based  on  the  Number  of  Vehicles  available.  One  of  the  outputs  of  the  model  is  a 
complete  listing  of  each  unique  Vehicle  with  its  unique  Vehicle  Number.  Many  of  these  vehicles  have  the 
same  characteristics  (as  specified  in  the  VehFleet,  VehData,  and  VehType  tables)  but  are  scheduled  on 
different  trips,  stops,  and  cargos. 


GDAS  Algorithm  Description 


4-27 


Database  Tables 


Field  Name 

Units 

Description 

Vehicle  Number 

Vehicle  unique  sequential  number 

Vehicle  Type 

Vehicle  type 

Vehicle  Identifier 

Vehicle  identifier 

Vehicle  Fleet 

Vehicle  fleet  for  this  vehicle 

Computed  Latitude 

deg  min  H 

Current  latitude  computed  for  the  current  date  and  time  in  the 
Param  table 

Computed  Longitude 

deg  min  H 

Current  longitude  computed  for  the  current  date  and  time  in  the 
Param  table 

Figure  4-43.  Output  Data  Elements  for  the  Vehicle  Table. 


4.6.2  Trip 

A  Trip  in  GDAS  is  defined  as  a  sequence  of  two  or  more  port  Stops  in  which  the  Vehicle  starts  out  empty, 
travels  to  multiple  pickup  and  delivery  ports,  and  finishes  empty  with  no  cargo  onboard.  Thus,  a  Trip 
represents  a  voyage  for  sealift  or  a  flight  for  airlift.  Each  trip  has  an  itinerary  consisting  of  at  least  two 

Stops. 


Field  Name 

Description 

1  Trip  Number 

Trip  number 

2  Vehicle 

Vehicle  assigned  to  this  trip 

3  Convoy  Trip  Number 

Convoy  trip  number  this  voyage  is  assigned  to,  if  any  (it  a  trip  has  multiple  convoys 
between  different  stops,  only  the  last  convoy  trip  is  stored  here) 

4  Number  of  Vehicle  Trips 

Number  of  vehicle  trips  assigned  to  this  trip 

Figure  4-44.  Output  Data  Elements  for  the  Trip  Table. 


4.6.3  Stop 

A  Stop  represents  a  POE  or  POD  port  visit  on  a  trip.  A  Stop  occurs  at  a  single  Facility  in  which  a  Vehicle 
performs  loading  or  unloading  of  cargos,  but  not  both.  (If  a  trip  has  both  loading  and  unloading  at  a  single 
port,  multiple  Stop  records  are  created  at  that  port.)  Each  stop  has  one  or  more  Cargos  for  loading  or 
unloading.  Each  Cargo  has  exactly  two  stops,  one  for  loading  and  one  for  unloading. 

A  Stop  has  an  arrival  and  departure  time,  which  is  tracked  by  hour  in  the  model  but  stored  as  Days  in  the 
database.  This  permits  the  model  to  evaluate  the  cumulative  effects  of  hourly  differences  such  as  load  rates, 
but  the  output  schedules  are  reported  by  Day  consistent  with  the  accuracy  of  the  data  inputs.  Currently,  all 
of  the  data  inputs  for  Ready  to  Load  Day  (RLD),  Required  Delivery  Day  (RDD),  Vehicle  Start  Day,  etc. 
are  accurate  only  to  the  nearest  day,  not  to  the  hour. 


Field  Name 

Units 

Description 

1  Stop  Number 

Unique  stop  number  for  this  port  or  node  facility  visit 

2  Arrive  Day 

day 

Arrive  day  at  the  stop  port  if  a  facility  is  available  (the  actual  arrive  day  can 
be  delayed  further  by  facility  constraints) 

3  Node 

Node  at  which  the  stop  is  made 

4  Facility  Name 

Port  or  node  facility  at  which  the  stop  is  made,  if  node  is  an  airport  or 
seaport 

5  Depart  Day 

day 

Depart  day  from  the  stop  port 

6  Is  Unload? 

“Yes”  flag  to  indicate  that  a  stop  is  for  unloading,  otherwise  blank 

7  Hours  Wait  for  Facility 

hr 

Hours  vehicle  spent  waiting  for  port  facilities  and  throughput  capacity  to 
arrive  or  depart 

8  Trip  Number 

Trip  number  associated  with  this  stop 

Figure  4-45.  Output  Data  Elements  for  the  Stop  Table 
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4.6.4  Cargo 

A  Cargo  represents  all  or  part  of  a  single  Movement  Requirement  and  Cargo  Category  that  is  loaded  onto 
one  Vehicle  Trip.  A  Cargo  is  associated  with  a  unique  Movement  Requirement,  Cargo  Category,  and 
Cargo  Type.  The  Quantity  of  the  Cargo  is  specified  in  the  Basic  Quantity  Measure  (Ston,  Cbbl,  Pax,  TEU, 
etc.)  for  its  Cargo  Category.  Each  Cargo  is  loaded  into  one  Vehicle  Compartment  at  one  POE  Stop  and 
unloaded  at  one  POD  Stop,  possibly  in  conjunction  with  other  Cargos  at  the  same  Stop  or  on  the  same  Trip. 
Each  Cargo  has  one  Predecessor  Cargo  for  the  previous  Transport  Mode,  except  for  the  initial  pickup  at  the 
Origin  Node.  Each  Cargo  can  be  split  into  one  or  more  Successor  Cargos  for  the  next  Transport  Mode, 
except  for  the  final  delivery  to  the  Destination  Node.  Successors  are  identified  from  Predecessor  linkages. 


Field  Name 

Units 

Description 

1  Cargo  Number 

Cargo  or  shipment  number 

2  Requirement  Id 

Requirement  identifier  for  this  cargo 

3  Cargo  Categoiy 

Cargo  categoiy  which  describes  the  kind  of  cargo  being  transported 

4  Cargo  Configuration 

Cargo  configuration  which  is  used  to  package  the  cargo  for  transport  on  one 
or  more  modes 

5  Cargo  Type 

Cargo  type  for  this  cargo 

6  Load  Stop  Number 

Load  stop  number  for  this  cargo  (in  the  model  after  planning  prior  to 
scheduling,  this  is  the  node  number) 

7  Unload  Stop  Number 

Unload  stop  number  for  this  cargo  (in  the  model  after  planning  prior  to 
scheduling,  this  is  the  node  number) 

8  Cargo  Basic  Quantity 

Q 

Cargo  quantity  in  the  basic  unit  of  measure  for  its  cargo  class  (ston,  pax, 
cbbl) 

9  Compartment  Type 

Vehicle  compartment  into  which  this  cargo  was  loaded 

10  Begin  Load  Day 

day  (hr) 

Day  that  the  cargo  begins  loading  (in  the  model  prior  to  simulation,  this  is 
the  earliest  possible  load  time  based  on  RLD  or  predecessor  cargo  or  earliest 
theater  depart  minus  10) 

1 1  End  Load  Day 

day  (hr) 

Day  that  the  cargo  completes  loading  (in  the  model  prior  to  simulation  this 
is  die  target  lift  time  or  planned  begin  load  time) 

12  Begin  Unload  Day 

day  (hr) 

Day  that  die  cargo  begins  offloading  (in  the  model  prior  to  simulation,  this 
is  also  the  earliest  possible  unload  time  based  on  EDD  for  final  destination 
cargos) 

13  End  Unload  Day 

day  (hr) 

Day  that  the  cargo  is  scheduled  to  complete  offloading  (this  is  updated 
during  planning,  scheduling,  and  simulation) 

14  Is  Attritted? 

T/F 

Checked  or  True  if  the  cargo  is  attritted  in  die  Fast  run  results,  otherwise 

False 

15  Attrit  Probability  %% 

%%  . . 

Calculated  cumulative  probability  of  attrition  (in  %%  or  ten  thousandths) 
for  the  cargo  based  on  its  route  and  schedule  and  including  the  probability 
of  attrition  of  prior  cargos 

i6  Cargo  Predecessor 

Unique  predecessor  cargo  which  immediately  precedes  this  cargo  and 
carries  die  same  requirement  (zero  for  an  origin  cargo) 

17  Cargo  Split  Id 

18  Planning  Fleet 

-  •  - . . 

Cargo  split  identifier  consisting  of  the  Requirement  Id  as  prefix,  followed 
by  each  successive  Cargo  Number  which  precedes  this  Cargo  Number 
Planning  fleet  selected  by  mode  planning  to  move  the  cargo 

19  Is  Final? 

T/F™” 

Checked  or  True  if  cargo  is  the  last  leg  to  the  final  destination 

20  Order  Number 

An  order  number  that  is  assigned  if  the  cargo  is  a  resupply  record,  matching 
an  order  in  RptSupSt 

Figure  4-46.  Output  Data  Elements  for  the  Cargo  Table 


4.6.5  Rejection  Reason 

Some  Cargos  may  not  be  successfully  planned  or  scheduled  by  the  GDAS  model.  These  Cargos  are  listed 
in  the  Rejection  Reason  table,  RejReas,  together  with  a  list  of  rejection  reasons  and  frequency.  This  is 
extremely  useful  in  identifying  data  problems  or  scenario  difficulties  which  prevent  successful  delivery. 
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Field  Name 

Description 

1  Cargo  Number 

Cargo  number  that  is  delayed  or  rejected 

2  Rejection  Type 

Rejection  reason  type 

3  Rejection  Count 

Count  of  rejections  for  this  cargo  and  rejection  reason  type 

Figure  4-47.  Output  Data  Elements  for  the  Rejection  Reason  Table  (RejReas). 


4.6.6  Convoy  Trip 

GDAS  has  the  ability  to  model  convoy  operations  between  Theaters,  normally  used  for  Sealift.  If 
convoying  is  performed,  then  several  Vehicle  Trips  may  be  assigned  to  a  single  Convoy  Trip  with  its 
associated  escorts.  These  Convoy  Trips  are  listed  in  the  ConvTrip  table. 

4.6.7  Generation  of  Reports 

Numerous  other  derived  tables  are  generated  to  provide  both  summary  and  detail  reports.  The  detail  reports 
include  Vehicle  Stop  Itineraries  (RptStop),  Vehicle  Stop  Itineraries  with  Cargo  (RptVeh),  Facility  Cargo 
Arrivals  (RptFacil),  Movement  Requirement  Cargos  (RptReq),  and  Cargo  Predecessor/Successor  Linkages 
(RptCargo).  Many  of  the  summary  reports  provide  daily  total  profiles,  including  Vehicles  in  Use 
(RptVehDy),  Required  versus  Delivered  Cargo  Totals  (RptTotal  by  Major  Unit,  RptTotS  by  Requirement 
Class),  Daily  Facility  Throughput  Capacity  (RptFCap),  Daily  Facility  Vehicle  Handling  (RptFVeh),  and 
Daily  Measures  of  Effectiveness  (RptMoe,  RptMoeS).  For  example.  Figure  4-48  lists  the  fields  for  the 
Required  Versus  Delivered  Total  Report  Table  (RptTotal). 


Field  Name 

Units 

Description 

1  Theater 

Theater 

2  Major  Unit 

Major  unit  for  this  total  delivery  record 

3  Cargo  Measure 

Cargo  quantity  measure  (ston,  pax,  cbbl,  mton,  sq  ft) 

4  Delivery  Day 

day 

Delivery  day 

5  Daily  Quantity  Required 

Q 

Incremental  quantity  required  on  this  day 

6  Daily  Quantity  Delivered 

Q 

Incremental  quantity  delivered  on  this  day 

7  Cumulative  Required 

Q 

Cumulative  quantity  required  by  this  day 

8  Cumulative  Delivered 

Q 

Cumulative  quantity  delivered  by  this  day 

9  Daily  %  Required 

% 

Incremental  %  of  total  major  unit  quantity  required  on  this  day  > 

10  Daily  %  Delivered 

% 

Incremental  %  of  total  major  unit  quantity  delivered  on  this  day 

1 1  Cumulative  %  Required 

% 

Cumulative  %  of  total  major  unit  quantity  required  by  this  day 

12  Cumulative  %  Delivered 

% 

Cumulative  %  of  total  major  unit  quantity  delivered  by  this  day 

Figure  4-48.  Output  Data  Fields  for  the  Required  Versus  Delivered  Total  Report  Table  (RptTotal). 


4.7  Special  Topics 

Many  special  transportation  issues  and  constraints  can  be  addressed  in  GDAS  using  additional  data  tables 
which  have  not  been  addressed  in  the  basic  discussion  above.  These  special  topics  and  their  related 
tables/fields  can  be  reviewed  in  GDAS  using  the  Inputs/Dictionary  Topics  menu.  Such  special  topics 
include  convoying,  attrition,  closure  calculations,  map  graphics,  special  missions,  and  penalties/priorities. 
The  related  data  elements  for  a  topic  may  be  stored  across  several  different  tables,  depending  on  the 
database  entities  that  are  affected.  For  example,  attrition  rates  for  time-dependent  exposure  are  defined  on 
links  in  the  NodeLink  table,  whereas  probabilities  for  discrete  attrition  are  defined  at  nodes  in  the  Node 
table,  and  attrition  adjustment  factors  are  defined  by  vehicle  type  in  the  VehType  table. 

4.7.1  Convoying 

In  both  the  planning  and  scheduling  phases,  convoying  is  implemented  as  part  of  the  underlying  node/link 
routing  procedures.  When  a  cargo  is  considered  for  loading  on  a  convoyable  vehicle,  the  POE  and  POD  is 
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known,  and  the  vehicle  makes  the  convoy  decision  based  on  the  policy  parameters  in  the  Param  table  and 
the  Convoy  table.  The  convoy  assembly  and  disassembly  nodes  must  be  be  in  different  theaters  in  traveling 
from  origin  to  destination.  Other  features  that  affect  convoying  include  the  ship  speed  (VehData  table),  the 
Max  Speed  Convoyed  (Param  table)  and  the  Convoy  Begin  Day  (Convoy  table)  and  the  Max  Diversion 
Distance. 

During  simulation,  the  number  of  escorts  available  for  each  convoy  route  are  tracked  to  determine  the 
actual  convoy  departure  times.  Attrition  calculations  for  convoys  are  handled  using  the  normal  method, 
taking  into  account  the  (possibly  different)  link  attrition  rates  and  node  attrition  probabilities  specified  for 
die  convoy  routes.  Returning  ships  also  use  the  convoy  route  and  therefore  incur  convoy  delays. 

The  convoys  created  in  the  model  are  output  to  the  ConvTrip  table  which  identifies  each  trip  in  the  Trip 
table  that  participated  in  the  convoy. 
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Table 

Field 

Key? 

Domain  or 
Lookup 

Units 

Description 

CONVOY 

Convoy 

Assembly  Node 

Yes 

FACILITY 

Assembly  node  for  ships  and  escorts  on  this 
convoy  route  (normally  in  the  origin  theater) 

CONVOY 

Assembly 

Facility 

Yes 

FACILITY 

Assembly  facility  for  ships  and  escorts  on 
this  convoy  route 

CONVOY 

Convoy 

Disassembly 

Node 

Yes 

FACILITY 

Final  disassembly  node  for  ships  and  escorts 
on  this  convoy  route  (normally  in  the 
destination  theater) 

CONVOY 

Disassembly 

Facility 

Yes 

FACILITY 

Final  disassembly  facility  for  ships  and 
escorts  on  this  convoy  route 

CONVOY 

Convoy  Route 
Type 

ROUTTYP 

E 

Convoy  route  type  which  can  accomodate  all 
ships  in  the  convoy 

CONVOY 

Convoy  Speed 

1,99 

knot 

Speed  at  which  all  convoy  ships  travel  on 
this  convoy  route 

CONVOY 

Convoy  Delay 
Hours 

HoursDela 

y 

hr 

Additional  convoy  transit  delay  time  in  hours 
for  management  operations,  diversions, 
assembly  and  disassembly  operations,  etc. 
after  the  convoy  assembly  day  and  before  the 
convoy  disassembly 

CONVOY 

Convoy  Interval 
Days 

DaysDelay 

ToHr 

day 

Minimum  time  interval  in  days  between 
scheduled  convoy  departures 

CONVOY 

Convoy  Min 
Vehicles 

0,999 

Minimum  number  of  ships  permitted  in  a 
convoy  trip 

CONVOY 

Convoy  Max 
Vehicles 

0,999 

Maximum  number  of  ships  permitted  in  a 
convoy  trip 

CONVOY 

Max  Vehicle 

Wait  Days 

DaysDelay 

ToHr 

day 

Maximum  ship  waiting  time  to  assemble  a 
minimum  size  convoy  beyond  which  the  ship 
sails  independently 

CONVOY 

Link  Attrit 
Multiplier  % 

% 

% 

Convoy  link  attrition  multiplier  for  ships  in 
this  convoy 

CONVOY 

Node  Attrit 
Multiplier  % 

% 

% 

Convoy  node  attrition  multiplier  for  ships  in 
this  convoy 

Param 

Scenario  Name 

Yes 

A8 

Scenario  short  name  and  directory  name 

Param 

Do  Convoying? 

Yesflag 

Yes  if  convoying  is  to  be  performed  using 
the  CONVOY  table,  blank  otherwise 

Param 

Do  Convoy  At 
Intervals? 

Yesflag 

Yes  if  convoys  are  to  be  scheduled  at  regular 
intervals  independent  of  convoy  size 
(convoys  can  then  be  scheduled  more 
efficiently) 

Param 

Convoy  Begin 

Day 

DayToHr 

day  (hr) 

Day  that  convoy  operations  begin 

§§(■1 

Max  Speed 
Convoyed 

1,99 

knot 

Max  speed  limit  above  which  ships  are  not 
convoyed  and  instead  travel  independently 

Param 

Max  Convoy 
Diversion 

Short>=0 

nmi 

Max  diversion  distance  above  which  ships 
are  not  convoyed  and  instead  travel 
independently 

Figure  4-49.  Input  Data  Tables  and  Fields  Related  to  Convoying. 
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Table 

Field 

Domain  or 
Lookup 

Units 

Description 

CONVTRIP 

Convoy  Trip 
Number 

Record# 

Vehicle 

Convoy  trip  number 

CONVTRIP 

Convoy 

Assembly  Node 

CONVOY 

Assembly  node  for  this  convoy  trip 

CONVTRIP 

Assembly 

Facility 

CONVOY 

H 

Assembly  facility  for  this  convoy  trip 

CONVTRIP 

Convoy 

Disassembly 

Node 

CONVOY 

■ 

Final  disassembly  node  for  ships  and  escorts  on  this 
convoy  trip 

CONVTRIP 

1 

CONVOY 

Final  disassembly  facility  for  ships  and  escorts  on  this 
convoy  trip 

CONVTRIP 

Convoy 

Assembly  Day 

DayToHr 

day 

(hr) 

Depart  day  of  the  convoy  at  the  assembly  point 

CONVTRIP 

Convoy 

Disassembly 

Day 

DayToHr 

day 

(hr) 

Depart  day  of  the  ships  in  the  convoy  at  the  disassembly 
point 

CONVTRIP 

Convoy  Size 

1,99 

Number  of  ships  in  the  convoy 

CONVTRIP 

Number  of 
Escorts 

1,99 

Number  of  escorts  in  the  convoy 

TRIP 

Trip  Number 

Record# 

BigStop 

Trip  number 

TRIP 

Convoy  Trip 
Number 

CONVTRIP 

Convoy  trip  number  this  voyage  is  assigned  to,  if  any  (if 
a  trip  has  multiple  convoys  between  different  stops,  only 
the  last  convoy  trip  is  stored  here) 

Figure  4-50.  Output  Data  Tables  and  Fields  Related  to  Convoying. 


4.7.2  Attrition 

In  GDAS,  the  travel  routes  and  distances  between  ports  for  each  ship  and  aircraft  are  expressed  in  terms  of 
nodes  and  links  on  an  intermodal  transportation  network.  The  general  approach  for  attrition  is  to 
decompose  the  overall  attrition  effects  into  individual  attrition  submodels  at  each  air  and  sea  port  and  on 
each  travel  link  between  ports.  By  associating  attrition  rates  with  each  port  and  link  separately,  the  analyst 
has  tremendous  flexibility  to  define  the  geographic  level  of  detail  by  adding  links  or  changing  individual 
link  probabilities.  In  addition,  the  time  variation  capability  of  GDAS  provides  the  capability  to  change  any 
or  all  attrition  rates  over  time.  For  modeling  flexibility,  the  attrition  factors  for  links  represent  exposure 
rates  (i.e.,  slower  travel  times  yield  greater  attrition),  whereas  the  attrition  factors  for  nodes  represent 
discrete  probabilities  per  visit.  The  attrition  rates  can  be  scaled  by  aircraft  or  ship  type  to  represent  different 
protection,  detection,  or  vulnerability  characteristics. 
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An  example  of  the  attrition  probability  calculations  is  provided  below: 

Formulas 

link  attrition  probability  = 

1  -  exp(  -  (link  attrition  rate/day)  *  (travel  time  in  days) ) 
node  attrition  probability  = 

(discrete  node  attrition  probability  applied  when  leaving  the  node) 

Sample  Data 

cargo  moves  via  “Airlift”  on  a  single  link  from  “Charleston”  to  “Jacksonville” 
link  data:  link  distance  =  180  mi 

link  delay  =  2  hr 
travel  speed  =  450  mph 

link  attrit  rate  =  200  %%/day  =  .2/day  (“%%”  denotes  a  %  of  a  %  or  .0001) 
node  data:  discrete  node  attrition  probability  of  10%  at  “Charleston” 

Sample  Attrition  Calculations 
travel  time 

180  mi/450  mph  +  2  hr  =  2.4  hr  =  .  1  day 
link  attrition  probability  = 

=  1  -  exp(- .2/day  *  .1  day) 

=  1  -  exp(-.02) 

=  .0198  (or- 2%) 

node  attrition  probability  =  .1  (or  10%) 
total  probability  of  attrition 

=  1  -  (probability  of  not  being  attrited) 

=  1  -  (probability  of  no  node  attrition)  *  (probability  of  no  link  attrition) 

=  1  -  (1  -  node  attrit  probability)  *  (1  -  link  attrit  probability) 

=  1  -  (.9)  *  (.9802) 

=  .1178  (1 178  %%  is  stored  in  the  database,  where  “%%”  is  a  %  of  a  %  or  .0001) 

During  simulation,  the  future  model  will  attrit  vehicles  using  the  input  attrition  data,  removing  attritted 
vehicles  from  the  scheduling  problem  after  completion  of  the  voyage  (i.e.,  after  cargo  has  been  off-loaded 
at  the  POD),  and  identifying  the  cargo  loaded  on  the  attrited  vehicle.  The  attritted  cargo  is  still  recorded  in 
the  database  with  delivery  and  closure  dates  as  if  it  had  not  been  on  the  attrited  vehicle.  Queries  and  reports 
can  be  generated  to  display  the  attrited  cargos  for  any  given  run. 

An  “expected  value”  form  of  the  attrition  calculation  is  available  for  analyzing  the  results  of  a  single  run. 
After  completion  of  a  simulation  run,  a  “conditional  expected  value”  calculation  processes  all  cargo 
delivered  during  the  simulation  (including  the  cargo  on  attrited  vehicles)  using  the  attrition  rates  which 
were  effective  on  the  links  at  the  time  the  cargo  moved  from  POE  to  POD.  This  conditional  expected  value 
determines  the  probability  of  attrition  for  each  cargo  and  calculates  the  expected  amount  of  cargo  that  is 
delivered  based  on  the  node/link  route  and  itinerary  of  each  cargo. 
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Table 

Field 

Key? 

Domain  or 
Lookup 

Units 

Description 

CONVOY 

Convoy  Assembly 
Node 

Yes 

FACILITY 

Assembly  node  for  ships  and  escorts  on  this 
convoy  route  (normally  in  the  origin  theater) 

CONVOY 

Assembly  Facility 

Yes 

FACILITY 

Assembly  facility  for  ships  and  escorts  on  this 
convoy  route 

CONVOY 

Convoy 

Disassembly  Node 

Yes 

FACILITY 

Final  disassembly  node  for  ships  and  escorts 
on  this  convoy  route  (normally  in  the 
destination  theater) 

CONVOY 

Disassembly 

Facility 

Yes 

FACILITY 

Final  disassembly  facility  for  ships  and  escorts 
on  this  convoy  route 

CONVOY 

Link  Attrit 
Multiplier  % 

% 

% 

Convoy  link  attrition  multiplier  for  ships  in 
this  convoy 

CONVOY 

Node  Attrit 
Multiplier  % 

% 

% 

Convoy  node  attrition  multiplier  for  ships  in 
this  convoy 

NODE 

Node  Name 

Yes 

A15 

Node  name  corresponding  to  a  port, 
transhipment  point,  origin,  destination,  routing 
point  etc. 

Attrit  Probability 
%% 

■ 

0,9999 

%% 

Discrete  probability  of  attrition  or  breakdown 
when  departing  this  node 

NODELINK 

From  Node 

Yes 

NODE 

From  node  name 

To  Node 

Yes 

NODE 

To  node  name 

NODELINK 

Transport  Mode 

Yes 

MODE 

Transport  mode  for  this  link  (only  one  link  is 
permitted  for  each  mode;  multiple  links  can  be 
created  by  adding  nodes) 

NODELINK 

Attrit  Daily  Rate 
%% 

0,9999 

%%/d 

ay 

Attrition  or  breakdown  rate  on  this  link  for 
exposure-based  attrition 

Param 

Scenario  Name 

A8 

Scenario  short  name  and  directoiy  name 

mm 

Do  Attrition? 

Yesflag 

Yes  if  attrition  or  breakdown  is  to  be 
performed,  blank  otherwise 

Random  Number 
Seed 

Short>=0 

Random  number  seed  for  stochastic 
simulations  including  attrition 

ReqType 

Requirement  Type 

Yes 

A15 

Requirement  type  or  unit  type 

ReqType 

Regeneration 

Delay  Days 

DaysDelayT 

oHr 

day 

(hr) 

Nonzero  delay  days  to  regenerate  attritted 
cargo  for  this  requirement;  cargo  is 
regenerated  with  the  same  data  as  the  original 
movement  (blank  means  no  regeneration) 

VEHTYPE 

Vehicle  Type 

mu 

SHAPE 

Vehicle  type  name,  e.g.  Breakbulk  for  sealift, 
C-17  for  airlift,  etc. 

VEHTYPE 

Link  Attrit 
Multiplier  % 

% 

% 

Attrition  adjustment  multiplier  applied  to  the 
link  attrition  or  breakdown  rate  for  this  vehicle 
type  while  in  transit  (blank  or  0  is  treated  as 
100%) 

VEHTYPE 

Node  Attrit 
Multiplier  % 

% 

% 

Attrition  adjustment  multiplier  applied  to  the 
node  attrition  or  breakdown  rate  for  this 
vehicle  type  while  at  the  node  (blank  or  0  is 
treated  as  100%) 

Figure  4-51.  Input  Data  Tables  and  Fields  Related  to  Attrition  (%%  denotes  a  %  of  a  %  or  .0001). 
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Table 

Field 

Key? 

Domain  or 
Lookup 

Units 

Description 

Cargo 

Cargo  Number 

Yes 

Record# 

BigStop 

Cargo  or  shipment  number 

Cargo 

Is  Attritted? 

Yesflag 

Yes  if  the  cargo  is  attritted  in  the  last  run  results, 
blank  otherwise 

Cargo 

Attrit 

Probability  %% 

0,9999 

%% 

Calculated  cumulative  probability  of  attrition  (in 
%%  or  ten  thousandths)  for  the  cargo  based  on 
its  route  and  schedule  and  including  the 
probability  of  attrition  of  prior  cargos 

RPTREQ 

ft  IlSnBtffPBI 

Yes 

Require 

Movement  requirement  or  package  id 

RPTREQ 

Basic  Quantity 
Measure 

ftp! 

MEASURE 

Basic  unit  of  measure  for  reporting  (ston,  pax, 
cbbl) 

RPTREQ 

Yes 

Cargo 

Cargo  or  shipment  number 

RPTREQ 

Is  Attritted? 

Yesflag 

Yes  if  the  cargo  is  attritted  in  the  last  run  results, 
blank  otherwise 

RPTREQ 

Attrit 

Probability  %% 

0,9999 

%% 

Calculated  cumulative  probability  of  attrition  (in 
%%  or  ten  thousandths)  for  the  cargo  based  on 
its  route  and  schedule  and  including  the  attrition 
of  predecessor  cargos 

RPTREQ 

Expected 

Quantity 

reqqn 

Expected  delivery  quantity  for  display, 
computed  as  the  cargo  quantity  times  the 
attrition  probability 

VEHICLE 

Vehicle 

Number 

Yes 

Record# 

Vehicle 

Vehicle  unique  sequential  number 

VEHICLE 

Attrit  or 

Damage  Day 

DayToHr 

day  (hr) 

Last  attrit  or  breakdown  day  for  this  vehicle,  if 
any 

Figure  4-52.  Output  Data  Tables  and  Fields  Related  to  Attrition  (%%  denotes  a  %  of  a  %  or  .0001). 
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4.7.3  Closure  Calculations 

Database  tables  and  fields  related  to  closure  calculations  are  listed  in  Figure  4-53.  A  unit  is  considered 
“closed”  when  the  specified  Closure  Required  Cargo  %  and  the  Closure  Required  Pax  %  arrive  at  the 
destination.  If  the  required  percentages  are  set  to  100%,  then  all  of  the  units  requirements  must  be  delivered 
to  count  as  closed. 


Table 

Field 

Key? 

Domain 

or 

Lookup 

InOut 

Units 

Description 

CARGCLAS 

Cargo  Class 

Yes 

A15 

Input 

Cargo  class  (Dry,  Pax,  POL)  which  defines 
dimensional  measures  for  cargo 

CARGCLAS 

Is  Pax? 

Yesflag 

Input 

Yes  if  the  cargo  class  represents  passengers, 
used  to  compute  closure  based  on  the 
MAJUNIT  %  closure  criteria 

MAJUNIT 

Major  Unit 

Yes 

A20 

Major  unit  name  for  analysis  of  requirement 
closures  and  measures  of  effectiveness 

MAJUNIT 

Computed 
Closure  Day 

DayToHr 

Output 

day 

(hr) 

Closure  day  for  the  major  unit  based  on  both 
the  Pax  and  cargo  closure  minimum  % 
specified  in  the  ReqType  table 

MAJUNIT 

Closure 
Required 
Cargo  % 

% 

Input 

% 

Minimum  percent  of  the  cargo  which  must 
be  delivered  in  order  to  calculate  unit  closure 
(if  the  %  is  never  attained,  closure  is  based 
on  the  last  portion  delivered) 

MAJUNIT 

Closure 

Required 

PAX  % 

% 

Input 

% 

Minimum  percent  of  the  passengers  which 
must  be  delivered  in  order  to  calculate  unit 
closure  (if  the  %  is  never  attained,  closure  is 
based  on  the  last  portion  delivered) 

ReqType 

A15 

Input 

Requirement  type  or  unit  type 

ReqType 

Assembly 
Delay  Days 

DaysDela 

yToHr 

Input 

day 

(hr) 

Additional  assembly  delay  days  needed  after 
deliveiy  at  the  destination  used  to  calculate 
closure  and  lateness  relative  to  the  RDD 

Require 

Requirement 

Id 

Yes 

A15 

Output 

Movement  requirement  or  package  id 

Require 

Computed 
Closure  Day 

DayToHr 

Output 

day 

(hr) 

Closure  day  for  the  requirement  based  on  the 
closure  minimum  %  requirement  specified  in 
the  ReqType  table 

RPTREQ 

Requirement 

Id 

Yes 

Require 

Output 

Movement  requirement  or  package  id 

RPTREQ 

Basic 

Quantity 

Measure 

Yes 

MEASUR 

E 

Basic  unit  of  measure  for  reporting  (ston, 
pax,  cbbi) 

RPTREQ 

Cargo 

Number 

Yes 

Cargo 

Output 

Cargo  or  shipment  number 

RPTREQ 

Computed 
Closure  Day 

DayToHr 

Output 

day 

Closure  day  for  the  requirement  based  on  the 
closure  minimum  %  requirement  specified  in 
the  ReqType  table 

Figure  4-53.  Data  Tables  and  Fields  Related  to  Closure  Calculations. 
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4.7.4  Map  Graphics 

Data  tables  and  fields  related  to  the  world  map  graphics  are  listed  in  Figure  4-54.  All  aspects  of  the 
drawing  display  can  be  controlled,  including  layers,  colors,  shapes,  and  sizes.  In  general,  these  parameters 
can  be  left  at  their  defaults  unless  a  particular  graphical  effect  is  desired. 


Table 

Field 

oiga 

Domain  or 
Lookup 

Description 

MapColor 

1  Color 

Yes 

A15 

Name  of  the  color  for  mapr  ^g  .  . . 

MapColor 

2  Red  intensity 

No 

Byte>=0 

Red  intensity  for  the  color 

MapColor 

3  Green  intensity 

No . 

Byte>=0 

Green  intensity  for  the  color 

MapColor 

4  Blue  Intensity 

No 

Byte>=0 

Blue  intensity  for  the  color 

MapFont 

1  Font  Name 

Yes 

A50 

Windows  Font  (or  Maplnfo  Helvitica,  Courier,  Times) 

MapFStyl 

1  Font  Style 

Yes 

A25 

Name  of  Font  sty  le 

MapFStyl 

2  Style  Value 

No 

Short>=0 

Maplnfo  value  for  this  Font  style 

MapLayer 

1  Layer  ID 

Yes 

Table  Any  Case 

The  unique  layer  ID  (generated  as  a  table  in  the  mapping 
application) 

MapLayer 

2  Layer  Label 

No  ‘ 

Menu  Item 

Layer  description  used  in  the  mapping  application  menus 

MapLayer 

3  Map  Table 

No 

MapTable 

Lookup  into  the  MapTable  table  for  the  original  table 

MapLayer 

4  Layer  Value 

No 

A255 

The  Layer  Field  value  for  this  layer 

MapLayer 

5  Begin  Off 

No 

Boolean 

True  if  the  layer  display  should  be  off  initially 

MapLayer 

6  Symbol  Type 

No 

MapSymbol 

MapLayer 

7  Symbol  Color 

No 

MapColor 

The  color  of  the  symbol  _ 

MapLayer 

8  Symbol  Size 

No ' 

0,48 

The  point  size  of  the  node  symbol  or  line  width 

MapLayer 

9  Symbol  Min 

Scale 

No 

Short>=0 

The  minimum  scale  (closest  in)  for  which  this  layer  is  displayed, 
express  as  width  of  view  in  miles 

MapLayer 

10  Symbol  Max 
Scale 

No 

Short>=0 

The  maximum  scale  (farthest  out)  for  which  this  layer  is  displayed, 
expressed  as  width  of  view  in  miles 

MapLayer 

11  Label  Font 

No 

MapFont 

The  font  type  for  the  layers  labels 

MapLayer 

12  Label  Style 

No 

MapFStyl 

The  font  style  for  the  layer  labels 

MapLayer 

13  Label  Color 

No 

MapColor 

The  font  color  for  the  layer  labels _ _  _ 

MapLayer 

14  Label  Size 

No 

Short>=0 

The  font  point  size  for  the  layer  labels 

MapLayer 

15  Label  Min  Scale 

No 

Short>=0 

The  minimum  scale  for  which  the  label  is  displayed,  expressed  as 
width  of  image  in  miles 

MapLayer 

16  Label  Max  Scale 

No 

Short>=0 

The  maximun  scale  for  which  the  label  is  displayed,  expressed  as 
width  of  image  in  miles 

MapLine 

1  Line 

Yes 

A25  . 

A  line  type  _  _  ^  _____  _ _____  ^  . .  _____ . 

MapLine 

2  Line  Value 

immmaam 

The  Maplnfo  numeric  value  for  this  line  type 

MapNode 

1  Node  Name 

Yes 

Node 

Node  name  or  location  extracted  from  NODE  for  the  world  map 
display 

MapNode 

2  Node  Type 

No 

NodeType 

Node  type  for  world  map  graphics  display 

MapNode 

3  Node  Latitude 

No 

Lat 

Node  latitude  (positive  is  North,  negative  is  South) 

MapNode 

4  Node  Longitude 

No”  " 

Lon 

Node  longitude  (positive  is  East,  negative  is  West) 

MapNode 

5  Is  Node 

Disabled? 

No . 

Boolean 

Checked  or  True  if  the  node  is  disabled,  otherwise  False 

MapShape 

1  Shape 

Yes . . 

A25 

A  shape  type 

MapShape 

2  Character  Value 

No 

Byte>=0 

The  Maplnfo  numeric  value  for  this  symbol  shape 

MapShape 

3  Font  Name 

No 

MapFont 

The  font  name  of  a  symbol  shape 

MapShape 

4  Font  Style 

No  ~ 

MapFStyl 

THe  font  style  for  this  symbol  shape  and  character  value 

MapSymb 

ol 

1  Map  Type 

Yes 

MapType 

The  type  of  mapping  display  appropriate  for  die  symbol  (Node  or 
Link) 

MapSymb 

o[ 

2  Symbol 

Yes 

A25 

A  symbol  available  for  the  mapping  levels,  either  a  shape  for 
nodes  or  a  line  type  for  links 

MapType 

i  Map  Type 

IBS 

A10 

Available  mapping  display  types 

Node" 

2  Node  Type 

No 

NodeType 

Node  type  for  world  map  graphics  display 

Node 

3  Node  Latitude 

No 

Lat 

Node  latitude  ^positive  is  North,  negative  is  South) _ _ 

Node 

4  Node  Longitude 

No 

Lon 

Node  longitude  (positive  is  East,  negatived  West} _ _ 
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NodeType 

Param 

1  Node  Type 

3  Vehicle  Snapshot 
Day 

Yes 

No 

A15 

simendday 

Param 

4  Vehicle  Snapshot 
Hour 

No 

Hour 

Vehicle 

8  Computed 

Latitude 

No 

Lat 

Vehicle 

9  Computed 
Longitude 

No . 

Lon 

Node  type  for  world  map  display  _ 

Current  day  used  to  interpolate  vehicle  locations  for  the  world  map 

display  #  _  _ _ _ _ 

Current  hour  used  to  interpolate  vehicle  locations  for  the  world 

map  display  _  _ _ _  _  j 

Currentlatitude  computed  for  foe  current  date  and  time  (positive  is 

North,  negative  is  South)  _ | 

Current  longitude  computed  for  foe  current  date  and  time  (positive 
is  East,  negative  is  West)  _ _ _ _ _ _ _ 


Figure  4-54.  Data  Tables  and  Fields  Related  to  World  Map  Graphics. 


4.7.5  Planning  and  Scheduling  Penalties  and  Priorities 

The  mode  planning  process  routes  a  movement  requirement  from  an  assigned  starting  node  (either  the 
initial  origin,  or  an  intermediate  origin  which  represents  the  end  node  of  a  previously  scheduled  cargo) 
through  the  transportation  network  to  its  final  destination,  possibly  through  several  modes  of 
transportation.  The  planning  process  uses  notional  travel  times  and  delays  set  in  the  Mode  table,  without 
treating  individual  vehicle  assignments.  The  planning  methodology  uses  a  node-oriented  shortest  path  type 
algorithm  as  a  outer  framework,  but  actually  uses  forward-reaching  dynamic  programming  to  evaluate 
alternate  states  at  each  node  since  multiple  penalty  criteria  must  be  evaluated  as  well  as  linking 
dependencies  to  other  scheduled  cargo. 

The  planning  process  uses  the  same  types  of  penalty  factors  for  cargo  delivery  timeliness  as  scheduling,  but 
relies  on  generic  vehicle  use  penalties  specified  for  each  transportation  mode  in  the  Mode  table.  Once  the 
preferred  transportation  network  path  has  been  identified  by  the  dynamic  programming  algorithm,  back¬ 
tracking  is  used  from  the  destination  RDD  to  set  a  Target  Lift  Date  (TLD). 

Scheduling  evaluates  each  candidate  lift  vehicle  with  preliminary  screening  tests  to  ensure  that  the  cargo 
and  vehicle  are  compatible,  the  vehicle  can  visit  the  cargo  ports,  and  that  special  mission  considerations  are 
compatible.  If  the  vehicle  passes  the  screening  tests,  then  a  more  detailed  route  insertion  algorithm  is 
executed  to  select  load  and  unload  stops  in  the  vehicle  route  and  to  estimate  marginal  insertion  penalties  for 
the  entire  vehicle  itinerary.  Finally,  the  vehicle  with  the  least  cost/benefit  ratio  is  selected  for  assignment. 

The  scheduling  then  performs  a  different  perspective  in  which  it  evaluates  other  promising  cargo 
assignments  for  the  same  vehicle  from  the  same  POE  port.  The  candidate  cargos  are  evaluated  using  the 
same  insertion  algorithm  and  penalties  as  before,  but  only  those  cargo/vehicle  assignments  with  marginal 
cost/benefit  less  than  the  value  of  the  Cost/Benefit  Threshold  in  the  Reqtype  table  for  that  Requirement 
Type,  are  immediately  assigned  to  the  vehicle.  This  second  evaluation  allows  a  quicker  load  out  of  the 
vehicle  and  improves  the  overall  efficiency  of  the  scheduler. 
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Table 

Field 

Domain  or 
Lookup 

Description 

Param 

7  Do  Static  Resupply? 

Boolean 

Tme  if  static  resupply  requirement  generation  is  to  be  performed 
(can  be  set  False  to  re-use  the  dynamic  resupply  computed  from  a 
prior  run) 

Param 

17  Personnel  Lead  Days 

DaysDelayToHr 

Earliest  lead  time  that  personnel  can  arrive  prior  to  other  cargo  in 

the  same  requirement  _ _ _ 

Nominal  penalty  per  ton  per  hr  for  transport  via  this  vehicle  type  for 
planning  routes  and  target  lift  dates 

PlanFlt 

6  Planning  Ton-Hour 
Penalty 

1,999 

PlanFlt 

12  Route  Delay  Penalty 

Short>=0 

Penalty  for  the  delay  of  prescheduled  stops  when  inserting  new 
stops,  the  input  value  is  the  penalty  of  one  day  delay  in  cents,  with 
increasing  cost  for  greater  delays 

ReqType 

4  Planning  Horizon  Days 

DaysDelayToHr 

Planning  or  look-ahead  horizon  in  days  for  scheduling  cargos  of 
this  requirement  type  prior  to  their  target  lift  date 

ReqType 

8  RDD  Tolerance 

DaysDelayToHr 

Days  tolerance  for  lateness  at  the  destination  relative  to  the  RDD 
before  mode  planning  increases  delivery  cost  to  reduce  lateness 

ReqType 

9  Max  Days  Late 

DaysDelayToHr 

Days  late  relative  to  the  target  delivery  date  beyond  which  a  cargo  is 
rejected  in  scheduling  and  is  reported  with  rejection  reasons,  even  if 
the  penalty  is  acceptable 

ReqType 

io  Cargo  Lateness 

Penalty 

0,100 

Penalty  for  cargo  ton-days  of  lateness  (as  compared  with  vehicle 
usage  penalties)  in  the  scheduling  algorithm 

ReqType 

1 1  Penalty/Benefit  Cut¬ 

off 

Long>=l 

Cost  cut  off  level  above  which  a  potential  cargo  assignment  is 
rejected  early  in  the  multi-port  scheduling  algorithm  (blank  or  a 
large  value  means  no  cutoff) 

ReqType 

12  Early  Assignment 

Level 

Short>=0 

Threshold  penalty/benefit  level  below  which  a  potential  cargo/ship 
assignment  is  accepted  immediately  in  the  multi-port  scheduling 
algorithm  (a  large  value  reduces  run  time  but  may  make  a  selection 
before  costing  a  preferred  vehicle)  _ _ _ 

ReqType 

14  Default  Priority  Order 

1,99 

Default  priority  order  for  Sis  requirement  type  if  not  specified  for  a 
given  requirement  (1  is  the  earliest  priority  order;  blank  is  treated  as 
no  priority  or  as  99) 

ReqType 

16  Integrity  Benefit 

DaysDelayToHr 

Wait  days  benefit  indicating  a  preference  for  loading  identical 
Requirement  Id’s  onto  the  same  vehicle  trip 

Require 

7  EDD 

DayToHr 

Earliest  allowed  delivery  day  of  the  requirement  at  its  destination 
prior  to  assembly 

Require 

9  Priority  Order 

1,99 

Relative  priority  order  for  this  requirement  as  a  secondary  sort  after 
the  Target  Lift  Date  (one  means  first  priority  in  assigning  lift  assets, 
blank  defaults  to  the  priority  order  of  the  requirement  type) 

StowPen 

4  Stow  Penalty 

Short>=0 

Stow  penalty  per  unit  basic  quantity  of  cargo  for  loading  into  this 
vehicle  compartment 

SuppReq 

8  Priority  Order 

1,99  ' 

Scheduling  priority  order  when  generation  movement  requirements 
for  resupply 

VehFleet 

12  New  Vehicle  Penalty 

Short>=0 

Penalty  for  the  first  use  of  a  new  vehicle  of  this  type  and  fleet 

VehType 

5  Time  Penalty 

6,999 

Penalty  for  vehicle  usage  per  hour,  used  to  compare  with  cargo 
lateness  in  the  scheduling  algorithm 

VehType 

6  Greedy  Vehicle  Level 

Limit  on  the  acceptable  cost/benefit  ratio  for  a  greedy  vehicle  trying 
to  get  additional  cargo  immediately  after  an  assignment 

VFacType 

6  Facility  Visit  Penalty 

Short>=0 

Penalty  for  multi-facility  visits  on  a  single  trip,  used  in  the 
scheduling  algorithm  (the  first  POE  and  POD  facilities  on  a  new  trip 
are  not  penalized) 

Figure  4-55.  Data  Tables  and  Fields  Related  to  Penalties  and  Priorities. 


4.7.6  Special  Missions 

Special  missions  permit  the  explict  assignment  of  certain  vehicles  or  vehicle  fleets  to  certain  movement 
requirements  for  a  specified  period  of  time.  Data  tables  and  fields  related  to  special  missions  are  listed  in 
Figure  4-56. 
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Table 

Field 

Is  Key? 

Domain  or 
Lookup 

Description 

Mission 

1  Special  Mission 

Yes 

A15 

Name  of  a  special  mission,  e.g.  Marine  amphibious  task  force,  or 
crane  ship,  or  other  mission 

Mission 

2  Mission  Begin  Day 

No 

DayToHr 

Begin  day  that  a  designated  special  mission  ship  or  fleet  is  restricted 
to  matching  special-mission  requirements  only 

Mission 

3  Mission  End  Day 

No 

DayToHr 

End  day  that  a  designated  special  mission  ship  or  fleet  is  restricted  to 
matching  special-mission  requirements  only 

Mission 

4  Delay  Hours  After 
Offload 

No 

HoursDelay 

Additional  delay  hours  in  the  depart  time  after  offload  of  special 
mission  cargo  at  its  ultimate  destination  node  (delays  the  vehicle  at 
the  stop,  not  the  cargo  delivery)  _ _ 

ReqMiss 

1  Requirement  Id 

Yes_ . 

Require 

Movement  requirement  having  a  special  mission 

ReqMiss 

2  Cargo  Class 

Yes 

CargClas 

Cargo  class  to  which  the  special  mission  applies  (Dry,  Pax,  etc.) 

ReqMiss 

3Mode . 

Yes 

Mode 

Transport  mode  to  which  the  special  mission  applies 

ReqMiss 

4  Special  Mission 

No 

Mission 

Special  mission  for  this  requirement,  cargo  class,  and  transport  mode 

VehFleet 

1  Vehicle  Type 

Yes 

VehData 

Vehicle  type 

VehFleet 

2  Vehicle  identifier 

Yes 

VehData 

Vehicle Identifier,  such  as  ship  name  or  aircraft  squadron,  for  this 
starting  location,  vehicle  type,  and  fleet 

VehFleet 

3  Vehicle  Fleet 

Yes 

FleetVehTy 

peFleet 

Fleet  identifier  for  this  starting  location 

VehFleet 

1 1  Special  Mission 

No 

Mission 

Special  mission  which  restricts  this  fleet  to  matching  special  mission 
movement  requirements  for  a  designated  period  of  time 

Figure  4-56.  Data  Tables  and  Fields  Related  to  Special  Missions. 


4.7.7  Prescheduled  Stops 

As  discussed  previously,  each  Planning  Fleet  can  be  assigned  a  prescheduled  stop  itinerary,  including 
cyclical  liner  routes  that  are  automatically  duplicated  and  expanded  into  multiple  trips.  This  automatic 
replication  saves  considerable  data  entry  for  multiple  cycles  and  vehicles.  Any  prescheduled  stops  that  are 
defined  for  die  Planning  Fleet,  as  listed  in  the  StdStop  table  for  that  fleet,  are  generated  and  expanded  prior 
at  the  beginning  of  the  model  run  and  are  retained  in  the  final  schedule.  For  example,  the  DOD  Voluntary 
Intermodal  Sealift  Agreement  (VISA)  program  makes  uses  of  commercial  liner  routes  which  have  preset, 
cyclical  itineraries.  Each  prescheduled  itinerary  is  listed  as  a  separate  Planning  Fleet  and  assigned  cyclical 
stops  in  the  StdStop  table. 

All  of  the  ships  in  a  given  Planning  Fleet  are  assigned  to  the  same  prescheduled  stops  in  StdStop,  if  they 
exist.  However,  the  individual  ships  on  a  route  are  typically  given  different  Start  Route  Offset  as  specified 
in  VehFleet.  For  example,  in  a  liner  operation  one  ship  may  arrive  and  depart  each  week,  so  the  Standard 
Depart  Interval  is  one  week  and  the  individual  ship  Start  Route  Offsets  differ  by  a  week.  If  the 
prescheduled  stops  are  cyclical  (they  start  and  stop  at  the  same  node),  then  the  prescheduled  itineraries  are 
automatically  repeated  over  time  until  the  end  of  the  simulation,  or  until  the  Start  Route  Last  Day  specified 
in  VehFleet.  The  data  tables  and  fields  related  to  prescheduled  stops  are  shown  in  Figure  4-57. 
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Field  Name 

Domain 

Units 

Description 

PlanFlt 

1 

Planning  Fleet 

Yes 

A15 

Aggregation  of  fleets  used  for  planning  modes,  ports, 
cargo  configurations,  and  prescheduled  routes 

PlanFlt 

10 

Standard  Depart 
Interval 

No 

Short>=l 

day 

Standard  depart  time  interval  for  a  prescheduled  route, 
stored  for  reference  only  and  not  used  to  generate 
routes 

PlanFlt 

If 

Stop  Arrival 
Tolerance 

No 

DaysDeiayto 

Hr 

day  (hr) 

Time  window  tolerance  for  early  or  late  arrival  at  the 
prescheduled  stops  on  this  route 

PlanFlt 

12 

Route  Delay 
Penalty 

No 

Short>=6 

Penalty  for  the  delay  of  prescheduled  stops  when 
inserting  new  stops,  the  input  value  is  the  penalty  of 
one  day  delay  in  cents,  with  increasing  cost  for  greater 
delays 

PlanFlt 

U 

Remain  On 
Route? 

No 

Boolean 

T/F 

Checked  or  True  if  the  prescheduled  ship  should  stay 
on  its  prescheduled  route  only  up  through  the  Route 
Last  Day,  otherwise  False 

PlanFlt 

Ul4“ 

Description 

No 

A50 

Description  of  the  prescheduled  route 

StdStop 

i!  1 

Planning  Fleet 

Yes 

PlanFlt 

Planning  fleet  that  has  prescheduled  stops 

StdStop 

2 

Stop  Sequence 

Yes 

Short>=l 

Stop  sequence  number  for  this  prescheduled  planning 
fleet  (stops  are  assumed  to  repeat  cyclically  if  the  first 
and  last  stop  have  the  same  node  and  facility) 

StdStop 

IP 

Arrive  Day 

No 

DayToHr 

day  (hr) 

Arrive  day  offset  for  this  prescheduled  stop  sequence, 
starting  from  zero  (the  actual  stop  time  is  depends  on 
the  offset  in  VEHFLEET  and  the  number  of  iterations^ 

StdStop 

4 

Node 

No 

Facility 

Node  associated  with  this  prescheduled  stop  sequence 
number 

StdStop 

5 

Facility 

No . 

Facility 

Facility  associated  with  this  prescheduled  stop 
sequence  number 

StdStop 

6  ] 

Depart  Day 

No 

DayToHr 

day  (hr) 

Depart  day  offset  for  this  prescheduled  stop  sequence, 
starting  from  zero 

VehFleet 

Vehicle  Type 

Yes 

VehData 

Vehicle  type 

VehFleet 

2 

Vehicle 

Identifier 

Yes 

VehData 

Vehicle  identifier,  such  as  ship  name  or  aircraft 
squadron,  for  this  starting  location,  vehicle  type,  and 
fleet  _  _ 

VehFleet 

3  1 

Vehicle  Fleet 

Yes 

FleetVehTyp 

e 

Fleet  identifier  for  this  starting  location 

VehFleet 

9 

Start  Route 
Offset 

No 

-99,999 

day 

Offset  day  for  this  fleet  and  vehicle  for  a  standard 
prescheduled  starting  route  cycle 

VehFleet 

io 

Start  Route  Last 
Day 

No 

DayToHr 

day  (hr) 

Last  day  beyond  which  the  prescheduled  starting  route 
is  no  longer  cycled 

Figure  4-57.  Data  Tables  and  Fields  Related  to  Prescheduled  Stops. 


An  example  is  helpful  to  understand  the  relationships.  Suppose  a  commercial  sealift  carrier  has  a  liner 
route  called  Transpacific  using  ships  named  Zeltec,  Gateway,  Brave  Bull,  Hornsby,  and  Adams.  The 
prescheduled  stop  sequence  for  the  Transpacific  route  is  entered  in  the  StdStop  table  as  shown  in  Figure 
4-58.  Note  that  it  is  a  cyclical  route  (starts  and  ends  at  Seattle),  with  relative  Arrive  Day  and  Depart  Day 
starting  at  day  0. 
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Planning  Fleet 

Stop  Sequence 

Arrive  Day 

Node 

Facility 

Depart  Day 

Transpacific 

1 

0 

Seattle 

Container 

2 

Transpacific 

2 

4 

Oakland 

Container 

6 

Transpacific 

3 

10 

Honolulu 

Container 

11 

Transpacific 

4 

19 

Guam 

Container 

20 

Transpacific 

5 

23 

Kaohsiung 

Container 

25 

Transpacific 

6 

35 

Seattle 

Container 

37 

Figure  4-58.  Prescheduled  Liner  Route  Example 


For  this  route,  the  ships  are  assigned  to  start  weekly,  7  days  apart.  This  is  specified  by  setting  die  Start 
Route  Offset  to  be  7  days  apart  for  each  ship  in  the  VehFleet  table.  The  offset  is  relative  to  the  0  Arrive 
Day  for  the  first  stop  in  Seattle  indicated  in  the  standard  route  in  StdStop.  If  the  Start  Route  Offset  numbers 
are  set  to  values  greater  than  0,  then  it  would  take  28  simulation  days  before  the  last  vehicle  entered  the 
simulation.  By  assigning  negative  offsets,  each  7  days  less  than  the  predecessor  ship,  the  ships  can  all  be 
underway  at  various  ports  in  the  route  when  the  simulation  starts  on  day  1,  as  follows: 


Vehicle  Identifier 

Start  Route  Offset 

Zeltec 

1 

Gateway 

-6 

Brave  Bull 

-13 

Hornsby 

-20 

Adams 

-27 

Figure  4-59.  Negative  Starting  Route  Offset  for  Ships  Arriving  Every  7  Days. 

In  this  way,  all  vehicles  are  in  route  no  later  than  day  8.  Note  it  is  a  good  idea  to  wait  until  all  vehicles  have 
made  their  first  stop  at  a  Node  before  scheduling  any  cargo  to  be  picked  up  by  them.  In  addition,  the  model 
does  not  simulate  day  0,  so  the  next  port  have  day  0  is  the  first  stop  in  the  simulation. 

4.7.8  Static  and  Dynamic  Resupply  Generation 

GDAS  can  now  generate  resupply  requirements  and  schedule  them  in  the  global  transportation  network, 
based  on  when  units  arrive  and  how  much  they  consume  resupply  from  inventory.  The  new  resupply 
features  are  invoked  by  entering  data  into  several  new  tables,  namely  SuppCons  (Supply  Consumption 
Rate),  SupStore  (Supply  Storage  Inventory),  SuppReq  (Suppy  Requirement),  and  SupQuan  (Supply 
Quantity  Density).  When  you  leave  these  tables  empty,  GDAS  operates  as  before  without  any  automatic 
resupply  generation.  When  resupply  is  generated,  GDAS  reports  the  results  of  dynamic  resupply  activities 
in  a  new  report  table  named  RptSupSt  (Report  Supply  Storage).  Additional  outputs  include  dynamically 
generated  resupply  orders  in  the  Require  and  ReqQuan  tables,  as  well  as  scheduled  resupply  cargos  in  the 
Cargo  table.  Tables  and  data  related  to  dynamic  and  static  resupply  generation  are  listed  in  Figure  4-60  and 
discussed  in  the  paragraphs  following. 
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Table 

D 

Field  Name 

Is  Key? 

Domain 

Units 

Description 

Param 

m 

Scenario  Name 

Yes 

A8 

Scenario  short  name  and  directory  name _ _ _ 

Param 

rm 

No 

Boolean 

T/F 

Checked  or  True  if  dynamic  resupply  generation  is  to 

Param 

7 

Do  Static  Resupply? 

No 

Boolean 

True  if  static  resupply  requirement  generation  is  to  be 

Param 

8 

1,99 

day  (hr) 

Aggregation  interval  for  computing  resupply  order 

ReqType 

1 

Requirement  Type 

Yes 

A15 

Requirement  type  or  unit  type 

ReqType 

17 

Is  Resupply? 

No 

Boolean 

true  or  checked  if  this  requirement  type  is  j 

Require 

1 

Requirement  Id 

Yes 

A15 

Movement  requirement  or  package  id 

Require 

10 

Supply  Requirement 

No 

SuppReq 

Supply  requirement  identifier  in  the  SUPPREQ  table, 

SuppCons 

1 

Consuming  Req 

Yes 

ReqType 

Requirement  type  that  consumes  resupply  in  the  £ 

SuppCons 

2 

Consumption 

theater 

Destination  theater  in  which  consumption  occurs 

SuppCons 

3 

Consuming  Cargo 

Yes 

CargoCat 

Consuming  cargo  category  for  estimating  consumption 

SuppCons 

4 

Cargo  Category 

Yes 

CargoCat 

Supply  cargo  category  that  is  stored  at  an  inventory 

SuppCons 

5 

Supply 

No 

0,999 

Q/(1000 

Daily  consumption  rate  expressed  as  supply  basic 

SuppCons 

o 

Accompany  Days  of 

No 

Byte>=0 

Q/(1000 

Accompanying  supply  quantity  in  days  of  supply  for 

SuppReq 

1 

Supply  Requirement 

Yes 

A15 

■  ■ 

Supply  requirement  identifier  for  static  and  dynamic 

SuppReq 

2 

Supply  Source  Node 

No 

Node . . 

■  B 

Resupply  origin  node 

SuppReq 

3 

No 

SupStore 

■ 

Resupply  cargo  category 

SuppReq 

4 

Supply  Storage 

No 

SupStore 

Resupply  storage  node  or  terminal  storage  location 

SuppReq 

5 

Supply  Major  Unit 

No 

MajUnit 

Resupply  major  unit,  which  has  a  requirement  type 

SuppReq 

6 

Supply  Availability 

No 

DayToHr 

day  (hr) 

Earliest  time  that  resupply  can  be  orderd  from  this 

SuppReq 

7 

Supply  Delivery 

No 

DayToHr 

day  (hr) 

Notional  resupply  delivery  time  or  lead  time,  usually  __ 

SuppReq 

8  ~ 

Priority  Order 

No 

1,99  . . 7 

Scheduling  priority  order  when  generation  movement 

SupQuan 

1 

Supply  Requirement 

Yes 

SuppReq 

Supply  requirement  identifier  matching  a  record  in _ 

SupQuan 

2 

Unit  of  Measure 

Yes 

MeasCargQuan 

Unit  of  measure  for  the  resupply  category 

SupQuan 

‘3 

Quantity 

No 

Long>=0  _ 

Q 

Relative  quantity  of  resupply  in  the  unit  of  measure. 

SupStore 

I 

Supply  Cargo 

Yes 

CargoCat 

Supply  cargo  category  that  is  stored  at  an  inventory 

SupStore 

2 

Supply  Storage 

Yes 

Nod£7J7Z 

Resupply  storage  node  or  terminal  forage  location _ 

SupStore 

3 

Prepositioned  Stock 

No . 

reqqn 

Q 

Quantity  of  reserved  stock  prepositioned  at  this  supply 

SupStore 

4 

Stock  Safety  Level 

No 

reqqn 

Q 

Minimum  safe  stockpile  level,  which  is  used  to 

SupStore 

5 

Stock  Order  to 

No . 

reqqn 

Q 

Target  stockpile  level  to  reorder  to  when  orders  are 

SupStore 

6 

Min  Order  Quantity 

No" . . 

Long>=l_ 

Q 

Minimum  order  quantity  for  this  supply  category  in 

Figure  4-60.  Tables  and  Fields  Related  to  Resupply  Generation. 


SuppCons.  This  table  contains  the  resupply  consumption  rates.  The  key  fields  represent  the  consumption 
rate  as  a  function  of :  the  consuming  Requirement  Type,  the  Consuming  Cargo  Category,  the  Consumption 
Theater,  and  the  Consumed  Cargo  Category.  Note  that  any  kind  of  Cargo  Category  can  consume  multiple 
kinds  of  any  other  Cargo  Category.  The  consumption  rate  is  measured  in  basic  quantity  consumed,  per 
1000  consuming  basic  quantity  units,  per  day.  For  example,  if  a  5  ton  vehicle,  measured  in  basic  quantity 
units  of  Stons,  consumes  1  barrel  of  POL  per  day,  then  the  arrival  of  a  cargo  containing  1000  Stons  of 
vehicles  will  begin  to  consume  200  barrels  of  POL  per  day.  If  you  set  GDAS  to  measure  POL  in  basic  units 
of  hundreds  of  barrels  per  day  (CBBL)  then  you  would  enter  2  as  the  consumption  rate  in  the  SuppCons 
table.  The  Accompany  Days  of  Supply  field  tells  GDAS  to  add  extra  resupply  to  the  theater  inventory 
when  the  consuming  requirements  arrive  at  their  destinations.  When  this  value  is  large,  you  will  see  the 
inventory  increase  on  the  same  day  that  cargos  arrive,  at  the  same  time  they  begin  to  consume  resupply. 

SupStore.  Each  record  in  the  SupStore  table  describes  a  storage  terminal  or  inventory  location  for  a 
consumable  cargo  category.  The  Prepositioned  Stock  represents  the  amount  of  cargo  at  the  storage  node  on 
the  day  the  scenario  begins.  The  inventory  policy  for  the  Supply  Storage  Node  storing  a  Supply  Cargo 
Category  is  controlled  by  the  values  for  Stock  Safety  Level,  Stock  Order  to  Level,  and  Minimum  Order 
Quantity.  When  GDAS  forecasts  that  the  inventory  will  go  below  the  safety  level  within  the  currently 
estimated  lead-time  for  shipment,  based  on  the  current  in-theater  consumption  rate,  GDAS  orders  enough 
cargo  to  bring  the  inventory  up  to  the  Order  to  Level.  GDAS  will  not  order  any  less  than  the  Minimum 
Order  Quantity.  The  size  of  the  Order  will  also  be  a  multiple  of  the  new  Discrete  Load  Increment  specified 
in  the  CargoCat  table. 
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SuppReq/SupQuan.  These  tables  are  analogous  to  the  Require  and  ReqQuan  tables,  except  that  the  are 
“templates”  for  ordering  new  resupply  requirements.  For  each  resupply  cargo  category,  these  tables  tell 
GDAS  where  the  cargo  will  come  from,  where  it  will  go  to,  when  it  can  be  available,  and  an  initial  estimate 
of  the  order  lead  time  used  for  initial  static  resupply  calculations  (the  lead  time  is  re-calculated  dynamically 
in  GDAS).  SupQuan  defines  relative  quantities  in  appropriate  units  of  measure;  the  absolute  quantities  are 
not  important,  only  the  ratios.  GDAS  derives  density  ratios  from  these  quantities  when  generating  resupply 
orders. 

ReqType.  A  new  field  called  “Is  Resupply?”  has  been  added  to  this  table.  GDAS-generated  resupply  cargo 
must  have  an  administrative  Requirement  Type  that  is  distinct  from  non-resupply  cargo.  Such  requirements 
will  be  overwritten  on  each  simulation  run,  as  GDAS  recreates  new  orders  and  shipments  to  sustain 
inventory  in  the  theater. 

Some  Cargo  Categories  can  serve  as  both  unit  cargo  and  resupply.  For  example,  roadable  vehicles  may  be 
included  in  unit  movements,  but  they  can  also  be  re-ordered  in  the  form  of  resupply  or  replacements  based 
on  unit  consumption  rates.  GDAS  uses  the  Cargo  Category  to  evaluate  physical  characteristics  of  the  cargo 
(e.g.,  in  CatMode);  it  uses  the  ReqType  of  the  movement  to  define  administrative  handling  characteristics. 
This  is  why  the  Is  Resupply?  Field  is  in  the  ReqType  table.  You  must  set  “Is  Resupply?”  to  “Yes”  for 
resupply  requirement  types  that  GDAS  will  generate.  Since  a  resupply  requirement  type  depends  on  the 
Major  Unit.,  you  need  to  make  sure  that  all  consumed  SuppReq  records  are  associated  with  Major  Units 
that  have  Requirement  Types  with  the  “Is  Resupply?”  flag  set.  In  addition,  you  should  not  specify  your 
own  input  movement  requirements  using  these  same  Major  Units,  since  GDAS  will  overwrite  these. 

Param.  This  Param  table  has  three  new  fields.  The  “Do  Static  Resupply?”,  if  set  to  Yes,  tells  GDAS  to 
create  static  Require  and  ReqQuan  resupply  records  from  the  SuppReq  and  SupQuan  tables  based  on  the 
original  unit  RDD’s.  GDAS  examines  the  input  movements  in  Require  and  ReqQuan,  along  with  the 
consumption  rates  in  SuppCons,  to  compute  initial  static  resupply  movements  over  the  simulation  time 
horizon.  These  static  requirements  are  used  for  initial  planning,  prior  to  dynamic  ordering  and  inventory  in 
the  theater.  The  “Static  Order  Interval”  represents  an  interval  of  days  and  tells  GDAS  how  to  aggregate 
resupply  quantities  for  the  static  calculation. 

The  “Do  Dynamic  Resupply?”  field,  if  set  to  Yes,  tells  GDAS  to  create  resupply  cargos  dynamically  as 
needed,  based  on  the  consumption  rates  when  the  consuming  cargos  actually  arrive. 

If  “Do  Static  Resupply?”  is  blank,  GDAS  will  create  resupply  cargos  from  any  resupply  requirements  that 
are  already  generated.  This  feature  can  be  used  to  feed  the  dynamic  requirements  from  one  run  into  GDAS 
as  static  calculations  for  the  next  run.  If  the  “Do  Dynamic  Resupply?”  field  is  blank,  then  no  dynamic 
orders  are  generated  as  units  arrive,  and  no  inventory  tracking  is  performed  in  the  simulation.  Instead,  the 
static  resupply  calculations  can  be  used.  And  if  both  fields  are  blank,  then  neither  static  nor  dynamic 
resupply  is  generated  by  GDAS  just  as  before,  and  the  SuppReq  and  SupStore  tables  are  ignored. 

RptSupSt.  This  new  output  table  contains  the  inventory  history  for  each  SupStore  inventory  location,  for 
each  day  of  the  plan.  From  RptSupSt  you  can  generate  charts  showing  inventory  on  hand,  quantity  on 
order,  and  simulative  demand  rate  for  each  inventory  location  and  cargo  category  in  SupStore,  for  each 
day  of  the  plan.  SupStore  also  reports  the  estimated  lead  time  and  the  order  number  if  a  reorder  occurs.  The 
estimated  lead-time  is  the  lead-time  GDAS  uses  to  dynamically  order  and  schedule  a  resupply  requirement. 
The  order  number  links  the  changes  in  inventory  to  specific  resupply  cargos  that  are  generated  in  the  Cargo 
table.  These  resupply  cargos  are  matched  to  generated  order  records  in  the  Require  table,  so  that  all 
totems  calculations  and  delivery  profiles  remain  accurate.  The  dynamic  resupply  movements  do  affect 
both  lateness  and  the  delivery  profiles. 
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Database  Type  Reference 


Table 

Label 

Table  Edit  Type 

Description 

LateClassExtra 

Extra  Lateness  Classifications 

Constant  Hide 

Stores  the  standard  lateness  classifications  that  are  always  appended  to 
the  RptLate  lateness  summary  report 

MapColor 

Mapping  Colors 

Edit 

Lists  the  available  colors  for  mapping  objects  (shapes  and  lines) 

MapFile 

Map  File  Paths 

Edit 

Lists  the  world  map  file  paths 

MapFont 

Mapping  Fonts 

Edit 

Lists  the  available  fonts  for  mapping  labels 

MapFStyl 

Mapping  Font  Styles 

Edit 

Lists  the  font  styles  for  mapping  labels 

MapLine 

Mapping  Line  Types 

Constant  NoEdit 

Lists  the  available  line  symbols  for  map  links 

MapShape 

Mapping  Shape  Types 

Edit 

Lists  the  available  shape  symbols  for  map  nodes  using  installed 
Windows  fonts 

MapSymbol 

Map  Layer  Display  Symbols 

Derive 

Lists  the  shape  and  line  symbols  by  mapping  type  available  for  the 
MapLayer  symbols. 

MapType 

Mapping  Table  Types 

Constant  NoEdit 

Lists  the  fundamental  mapping  table  types  (Node  or  Link) 

MeasClas 

Measure  Class 

Constant  NoEdit 

Defines  the  measurement  classes  (e.g.  Cargo  Quantity,  Max  Cargo  Item 
Dimension,  Vehicles  Per  Day,  MOG  or  #  Berths,  Vehicle  Dimension, 

RejType 

Rejection  Type 

Constant  NoEdit 

Lists  the  available  delay  reason  types 

SchedTyp 

Scheduling  Type 

Constant  NoEdit 

Lists  the  scheduling  model  algorithm  types 

VaryDist 

Vary  Distribution 

Constant  NoEdit 

Stochastic  or  parametric  distribution  types  for  sampling  data 

VaryParD 

Vary  Parametric  Data 

Display  Only 

Lists  allowable  tables  and  data  fields  for  users  to  vary  either 
parametrically  or  as  time  variations 

VarySavD 

Vary  Storable  Data 

Future 

Lists  the  allowable  tables  and  fields  which  can  be  saved  over  multiple 

parametric  or  stochastic  runs 
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Database  Type  Scenario 


Table 

Label 

Table  Edit  Type 

Description 

BasMeas 

Basic  Measure 

Edit 

Lists  basic  measures  for  reporting  primary  cargo  quantities  (Ston,  Cbbl, 
Pax);  each  cargo  class  has  a  basic  measure  used  for  quantity  splits 

CargCIas 

Cargo  Class 

Edit 

Lists  the  major  cargo  classes  (e.g.,  Dry,  PAX,  POL)  that  define  which 
dimensional  measures  are  applicable  to  each  cargo  category  and  cargo 

CargConf 

Cargo  Configuration 

Edit 

Lists  the  cargo  configurations  used  to  containerize,  package,  or  modify 
cargo  for  transport,  and  sets  the  time  rate  for  configuration 

CargoCat 

Cargo  Category 

Edit 

Lists  the  cargo  categories  which  specifies  the  kind  of  cargo  at  the  most 
detailed  level,  often  based  on  JOPES  three-position  cargo  category  plus 

CargType 

Cargo  Type 

Edit 

Lists  the  cargo  types,  which  define  kinds  of  cargo  affecting  stow 
factors,  load  rates,  and  load  compatibility  for  a  specific  mode  of 

CatGroup 

Category  Group  for  Charts 

Edit 

Defines  groupings  of  cargo  categories  which  can  be  used  to  selectively 
display  total  quantities  in  delivery  profile  charts 

CatMeas 

Category  Measure 

Derive 

Lists  the  dimensional  measures  applicable  to  each  cargo  category; 
generated  automatically  from  the  CLASMEAS  table  to  provide  a 

CatMode 

Cargo  Category  Mode 

Keys  Full 

Lists  the  conversion  of  cargo  categories  to  mode-specific  cargo  types 
which  define  stow  factors  and  load  rates  for  each  vehicle  type 

ClasMeas 

Cargo  Class  Measure 

Edit 

Lists  the  major  classes  of  cargo  and  what  quantity  measures  are 
applicable 

Convoy 

Convoy 

Edit 

Specifies  information  about  convoy  routes  which  are  to  be  used  for 
sealift  when  traveling  between  the  assembly  node  theater  and  the 

CptMeas 

Compartment  Measure 

Edit 

Lists  the  measures  for  defining  compartment  capacity 

CptType 

Compartment  Type 

Edit 

Defines  vehicle  compartment  types 

Exclude 

Exclusion 

Edit 

Sets  user-definable  exclusions  for  cargo  loading,  based  on  various 
combinations  of  factors  such  as  Mode,  Vehicle  Type,  Cargo  Category, 

FacCap 

Facility  Capacity 

Edit 

Specifies  facility  limits  and  constraints  on  cargo  throughput  for  different 
facility  measures 

Facility 

Facility 

Edit 

Lists  port  facilities  at  nodes 

FacType 

Facility  Type 

Edit 

Lists  the  available  facility  or  berth  types  which  are  used  to  define  load 
rates  at  port  facilities 

Fleet 

Administrative  Fleet 

Edit 

Identifies  groups  of  vehicles  with  common  administrative 
characteristics  for  vehicle  availability. 
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LateClass 

Late  Days  Groups 

Edit 

Defines  groups  by  days  late  for  the  RptLate  lateness  summary  report 

LinkCap 

Node  Link  Capacity 

Edit 

Defines  the  capacity  for  constrained  links  and  units  of  measure 

LoadRate 

LoadRate 

Keys  Computed 

Specifies  transfer  rates  for  loading  and  unloading 

MajUnit 

Major  Unit 

Edit 

Lists  each  major  unit,  which  in  GDAS  is  a  grouping  of  requirements, 
either  unit  or  non-unit,  used  to  display  delivery  profiles  and  compute 

MapLayer 

Mapping  Layer  Specs 

Update 

Sets  mapping  layer  characteristics  such  as  color  and  symbol  which  can 
be  edited  by  the  user 

MapTable 

Mapping  Table  Specs 

Hide 

Defines  the  map  table  specifications 

Measure 

Measure 

Edit 

Lists  the  types  of  dimensional  measures  used  to  define  cargo,  vehicle 
compartments,  or  node  facilities 

Mission 

Mission 

Edit 

Lists  special  missions  such  as  TACS,  AFOE,  etc. 

Mode 

Mode  of  Transport 

Edit 

Lists  transportation  modes  (air,  sea,  motor,  organic,  rail,  intratheater  air, 
etc.) 

Node 

Node 

Edit 

Lists  nodes  and  locations  for  all  ports,  origins,  destinations, 
transhipment  points,  and  routing  points 

NodeCap 

Node  Capacity 

Edit 

Defines  total  throughput  at  each  node  for  all  facilities  at  the  node 

NodeLink 

Node  Link 

Edit 

Lists  single  leg  links  between  nodes  for  transportation 

NodeType 

Node  Type  for  Mapping 

Edit 

Lists  the  node  types  for  world  map  display 

Param 

Parameter 

Modify 

Sets  parameters  for  the  scheduling  model 

PlanFlt 

Planning  Fleet 

Edit 

Lists  the  fleet  aggregations  used  for  planning  modes,  ports,  cargo 
configurations,  and  pre-scheduled  routes 

PlnFltTr 

Plan  Fleet  Transfer 

Keys  Full 

Specifies  the  allowable  fleet  to  fleet  transfers 

ReqClass 

Requirement  Class 

Edit 

Lists  the  aggregated  requirement  classes  for  calculating  summary  cargo 
delivery  versus  required  totals  for  reports 

ReqFleet 

Required  Fleet 

Edit 

Defines  the  allowable  fleets  by  mode  for  a  requirement  type,  if  the 
requirement  type  is  restricted  to  certain  fleets 

Reqlmprv 

Dynamic  FacCap  Change 

Edit 

Defines  how  the  delivery  of  a  requirement  improves  facility  throughput 
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ReqLag 

Requirement  Link  Lag 

Edit 

Defines  timing  links  between  delivery  of  independent  and  dependent 
requirements 

ReqMiss 

Required  Mission 

Edit 

Lists  special  missions  for  requirements,  cargo  classes,  and  modes 

ReqMode 

Excluded  Mode  by  Req 

Edit 

Lists  excluded  modes  for  specific  requirements  and  cargo  classes 

ReqNImpr 

Dynamic  NodeCap  Change 

Edit 

Defines  how  the  delivery  of  a  requirement  improves  node  throughput 

ReqNode 

Required  Node 

Edit 

Lists  required  intermediate  POE  or  POD  nodes  or  ports  for  movement 
requirements  with  specified  staging,  POE/POD  time  frames,  and  mode 

ReqQuan 

Requirement  Quantity 

Edit 

Provides  quantity  data  for  each  movement  requirement  and  cargo 
category 

ReqRet 

Requirement  Return 

Future 

Lists  requirement  return  or  transfer  days,  if  any,  for  removing 
requirements  from  a  theater  and  eliminating  its  supply  consumption  and 

ReqTypc 

Requirement  Type 

Edit 

Provides  data  about  requirement  types  or  unit  types 

Require 

Requirement  to  Move 

Edit 

Provides  information  about  each  movement  requirement  or  package 

RoutExcl 

Route  Exclusion 

Edit 

Lists  excluded  facility  types  for  refueling  on  the  various  route  types 

RoutType 

Route  Type 

Edit 

Provides  route  type  data  for  determining  vehicle  paths,  including 
refueling  range,  refueling  facility  requirements,  and  payload  versus 

Service 

Service 

Edit 

Lists  the  U.S.  military  services 

Stage 

Stage  Location 

Future 

Lists  the  staging  deployments  which  have  predecessor  and  successor 
requirements 

StdStop 

Standard  Stop 

Edit 

Defines  the  stop  sequence  for  standard  prescheduled  routes  used  in 
vehicle  intialization;  the  stops  repeat  cyclically  if  the  first  node  and 

StowFact 

Stow  Factor 

Keys  Computed 

Specifies  the  stow  factor  for  each  combination  of  compartment  type  and 
cargo  type 

StowPen 

Stow  Penalty 

Keys  Computed 

Lists  combinations  of  compartment  types  and  cargo  types  along  with 
stow  penalties 

SuppCons 

Supply  Consumption 

Future 

Specifies  standard  daily  consumption  rates  of  resupply  for  consuming 
requirements 

SuppReq 

Supply  Requirements 

Edit 

Lists  the  information  needed  to  generate  static  and  dynamic  resupply 
requirements 

SupQuan 

Supply  Quantities 

Keys  Computed 

Lists  the  units  of  measure  and  relative  quantities  as  density  information 
for  generating  resupply  movements 
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SupStore 

Supply  Destination 

Edit 

Provides  data  about  resupply  storage  terminals  in  the  theater 

Theater 

Theater 

Edit 

Provides  data  about  the  theaters 

ThtrReq 

Theater  Require  Type 

Keys  Full 

Provides  data  about  passenger  weights  by  theater  and  requirement  type 

TimeVaiy 

Time  Variation 

Edit 

Specifies  data  which  changes  over  time  (derived  from  user  inputs  in  the 
associated  data  tables,  should  not  be  edited  directly) 

Vary  Par 

Vary  Parameter 

Future 

Specifies  data  elements  to  be  varied  parametrically 

VarySave 

Vary  Save  Data 

Future 

Defines  data  to  be  saved  across  multiple  runs  when  data  elements  have 
parameter  variations  or  sampling  distributions 

VaryStat 

Vary  Sampled  Data 

Future 

Lists  tables  and  data  elements  which  are  sampled  from  a  stochastic 
distribution  taking  as  mean  the  database  value 

VCptType 

Veh  Cpt  Type 

Edit 

Lists  the  compartments  available  for  each  vehicle  type 

VehCap 

Vehicle  Capacity 

Keys  Computed 

Defines  load  capacities  for  each  vehicle  identifier,  compartment,  and 
unit  of  measure 

VehData 

Vehicle  Data 

Edit 

Provides  detailed  characteristics  about  each  kind  of  vehicle  identified  in 
the  system 

VehFleet 

Vehicle  Availability  Fleet 

Edit 

Lists  the  availability  of  vehicles  by  starting  location  or  route,  starting 
time  for  scheduling,  and  number  of  vehicles 

VehType 

Vehicle  Type 

Edit 

Lists  vehicle  types  by  transport  mode 

VFacDim 

Vehicle  Dimension  Limit 

Edit 

Sets  cargo  dimension  limits  for  loading  onto  vehicle  types  at  facility 
types 

VFacType 

Vehicle  Facility  Type 

Keys  Computed 

Lists  matchings  of  vehicle  types  and  facility  types  for  loading/unloading 
cargo 
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Database  Type  Tpfdd 


Table 

Label 

Table  Edit  Type 

Description 

ACrgType 

JOPES  Air  Cargo  Type 

Edit 

Lists  the  JOPES  air  cargo  types  (Bulk,  Oversize,  etc.)  and  their 
maximum  dimensions 

AggCat 

Aggr  Cargo  Category 

Edit 

Provides  translations  for  aggregating  cargo  category 

AggMajun 

Aggr  Major  Unit 

Edit 

Provides  translations  for  aggregating  major  unit 

AggMode 

Aggr  Required  Mode 

Edit 

Provides  translations  for  aggregating  required  transport  mode 

AggNode 

Aggr  Node 

Edit 

Provides  translations  for  aggregating  node  location 

ccc 

JOPES  Cargo  Cat  Code 

Edit 

Lists  the  three  character  JOPES  cargo  category  codes 

CCC1 

JOPES  Cargo  Cat  Posl 

Edit 

Lists  the  first  position  of  the  JOPES  cargo  category  code,  which  defines 
the  kind  of  cargo 

CCC2 

JOPES  Cargo  Cat  Pos2 

Edit 

Lists  the  second  position  of  the  JOPES  cargo  category  code,  which 
defines  the  airlift  cargo  type  and  the  unit  class  (Unit  Equip,  Acc  Supply, 

CCC3 

JOPES  Cargo  Cat  Pos3 

Edit 

Lists  the  third  position  of  the  JOPES  cargo  category  code,  which 
defines  containerizability 

CCC4 

Custom  Cargo  Cat  4 

Edit 

Lists  a  customizable  fourth  position  cargo  category  code,  which 
specifies  user-definable  cargo  item  dimensions 

ClassiflC 

JOPES  Classif  Code 

Edit 

Lists  the  JOPES  security  classification  codes 

CntrType 

Container  Type 

Edit 

Lists  the  containerizability  types  corresponding  to  the  third  position  of 
the  JOPES  Cargo  Category  Code 

CntrySt 

JOPES  Country  State 

Edit 

Lists  the  JOPES  country  state  codes  and  names 

CrgDtLvl 

JOPES  Crg  Detail  Lev 

Edit 

Lists  the  JOPES  TUCHA  and  TPFDD  cargo  detail  levels 

DelReas 

NonUnit  Delay  Reason 

Edit 

Lists  the  JOPES  codes  for  non-unit  intermediate  stop  delay  reasons 

DelType 

Unit  Delay  Type 

Edit 

Lists  the  JOPES  codes  for  unit  intermediate  stop  delay  type,  either  total 
force  or  force  increments 

Deploylc 

JOPES  Deploy  Indie 

Edit 

Lists  the  JOPES  deployment  indicator  codes  which  characterize 
deployability 
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DischCfg 

JOPES  Discharge  Code 

Edit 

Lists  the  JOPES  discharge  constraint  codes 

FIC 

JOPES  Force  Indicate 

Edit 

Lists  the  JOPES  force  indicator  codes 

FuelType 

Fuel  Type  Code 

Edit 

Lists  the  JOPES  fuel  types 

GeoDate 

Geoloc  Date 

Edit 

Stores  the  geoloc  file  date 

Geoloc 

Geolocation 

Edit 

Stores  the  imported  geoloc  data  from  the  JOPES  Geofile 

HeavLift 

JOPES  Heavy  Lift 

Edit 

Lists  the  JOPES  heavy  lift  codes 

Import 

Import  Specification 

Edit 

Provides  table,  record,  and  field  specifications  for  importing  data  from 
external  databases 

InstType 

Installation  Type 

Edit 

Lists  the  JOPES  Geolocation  installation  type  codes 

LoadCfg 

JOPES  Load  Config 

Edit 

Lists  the  JOPES  load  configuration  codes 

LogCode 

JOPES  Logistics  Code 

Edit 

Lists  the  JOPES  Geolocation  logistics  planning  codes 

MajCat 

Major  Cargo  Category 

Edit 

Lists  the  major  cargo  categories  corresponding  to  the  first  position  of 
the  JOPES  cargo  category  code 

Mode_Src 

JOPES  Mode  &  Source 

Edit 

Lists  the  JOPES  transport  mode  and  source  code  combinations 

ModeCode 

JOPES  Move  Type  Code 

Edit 

Lists  the  JOPES  transport  mode  codes 

NUMoveTp 

JOPES  Non  Unit  Type 

Edit 

Lists  the  JOPES  non-unit  type  movement  codes 

NURecTyp 

Non  Unit  Record  Type 

Edit 

Lists  the  JOPES  TPFDD  non-unit  record  types  for  Pax  and  Cargo 

OrgCode 

JOPES  Organization 

Edit 

Lists  the  JOPES  organization  and  service  codes 

PIC 

JOPES  Parent  Indicat 

Edit 

Lists  the  JOPES  parent  indicator  codes  which  describe  subordinate 
splitting 

PoiLoc 

JOPES  POI  Location 

Edit 

Lists  the  JOPES  intermediate  port  location  codes 

RecCode 

JOPES  Record  Indicat 

Edit 

Lists  the  JOPES  record  indicator  codes 
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StopCode 

JOPES  Stop  Code 

Edit 

Lists  the  JOPES  stop  reason  codes 

SupClasl 

JOPES  Supply  Class  1 

Edit 

Lists  the  JOPES  major  supply  class  code  in  position  1 

SupClass 

JOPES  Supply  Class 

Edit 

Lists  the  JOPES  two-character  supply  class  and  subclass  codes 

Tpld 

TPFDD  Ident 

Edit 

Stores  the  imported  TPFDD  Identifier  record 

TpNonUnt 

TPFDD  Non  Unit 

Edit 

Stores  the  imported  TPFDD  Non  Unit  cargo  and  pax  records 

TpSrfCat 

TPFDD  SRF  Category 

Edit 

Stores  the  imported  TPFDD  SRF  category  records  for  non-standard  units 

TpSrfDet 

TPFDD  SRF  Detail 

Edit 

Stores  the  imported  TPFDD  SRF  detail  records  for  non-standard  units 

TpSrfld 

TPFDD  SRF  Went 

Edit 

Stores  the  imported  TPFDD  SRF  identifier  records  for  non-standard 
units 

TpUnit 

TPFDD  Unit 

Edit 

Stores  the  imported  TPFDD  standard  force  unit  records 

TranpSrc 

JOPES  Tmsprt  Source 

Edit 

Lists  the  JOPES  transport  source  providing  organization  codes  (MSC, 
MTMC,  etc.) 

Translat 

Translation  Table 

Edit 

Defines  translations  based  on  direct  conversions,  translation  tables,  or 
function  mappings  for  importing  data  from  external  databases 

TuCat 

TUCHA  F2  Category 

Edit 

Stores  the  imported  TUCHA  F2  cargo  category  quantities  for  standard 
unit  types 

TuDate 

TUCHA  Date 

Edit 

Stores  the  imported  TUCHA  date 

TuDet 

TUCHA  F3  Detail 

Edit 

Stores  the  imported  TUCHA  F3  detail  cargo  quantities  and  dimensions 
for  standard  unit  types 

TuOldUtc 

TUCHA  AB  Total 

Edit 

Stores  the  imported  TUCHA  AB  records  containing  updated  UTC 
status,  often  cancelled 

TuUtc 

TUCHA  UTCs  and  Air 

Edit 

Stores  the  imported  TUCHA  ABF1  UTC  records,  including  total  air 
cargo  type  quantities 

ULC 

UNIT  Level  Code 

Edit 

Lists  the  JOPES  unit  level  codes 

UnitClas 

JOPES  Unit  Class 

Edit 

Lists  the  JOPES  unit  classifications  (Unit  Equip,  Acc  Supply,  Organic) 

UnitStat 

JOPES  Unit  Status 

Edit 

Lists  the  JOPES  unit  status  codes  (active,  canceled) 
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UtcFunct 


JOPES  UTC  Function 


Edit 


Lists  the  JOPES  Unit  Type  Code  functional  area  which  is  the  first 
position  of  the  Unit  Type  Code 


UtcSubst 


UTC  Substitution  Edit 


Lists  the  Unit  Type  Code  substitutions  for  standard  units  that  have  no 
match  in  the  TUCHA  data 
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Appendix  B 
Data  Dictionary 

The  Data  Dictionary  provides  a  complete  definition  of  the  tables,  fields,  key  fields,  domains,  lookups,  units  of  measures,  and 
descriptions  in  the  GDAS  system.  The  online  Help/Data  menu  provides  immediate  access  to  the  Data  Dictionary  while  you 
are  editing  tables.  One  of  the  most  valuable  uses  of  the  Data  Dictionary  is  to  understand  the  relationships  between  tables  so 
that  you  can  work  in  a  consistent,  top-down  fashion  in  defining  new  records  in  GDAS  (e.g.,  for  adding  a  new  Transport 
Mode). 

The  complete  Data  Dictionary  is  provided  in  the  pages  following.  An  extract  for  the  VehFleet  table  is  shown  in  the  figure. 
The  first  boxed  lists  the  8  character  table  name  VehFleet,  its  long  table  name  Vehicle  Fleet,  and  a  description  of  the  table. 
Below  the  table  information  is  a  list  of  fields  belonging  to  the  table  along  with  field  definitions.  In  the  field  list,  the  first 
column  repeats  the  table  name,  VehFleet.  The  second  column  lists  the  field  number  and  field  name,  e.g.  the  first  field  is 
Vehicle  Type. 


VEHFLEET  Vehicle  Fleet  |  Lists  the  availability  of  vehicles  by  starting  location,  starting  time, 

J  and  number  of  vehicles 


J 


Domain/ 

Table  Field  Name  Lookup  Key?  In/Out  Unit  Meas  Description 

_ 1 _ _ J _ I _ I - 1 - 1 - 


VEHFLEET 

1 

Vehicle  Type 

VEHDATA 

Y 

In 

VEHFLEET 

2 

Vehicle  Identifier 

VEHDATA 

Y 

In 

VEHFLEET 

3 

Vehicle  Fleet 

A15 

Y 

In 

VEHFLEET 

4 

Number  of  Vehicles 

Short>=0 

In 

VEHFLEET 

5 

Start  Node 

FACILITY 

In 

VEHFLEET 

6 

Start  Facility 

FACILITY 

In 

home 

VEHFLEET 

7 

Start  Day  Available 

DayToHr 

In 

VEHFLEET 

8 

Last  Day  Returned 

DayToHr 

In 

VEHFLEET 

9 

Special  Mission 

MISSION 

In 

VEHFLEET 

10 

New  Vehicle  Penalty 

Short>=0 

In 

VEHFLEET 

11 

Call  Sign 

A4 

In 

VEHFLEET 

12 

NISC  Number 

A5 

In 

Vehicle  type 

Vehicle  identifier  for  this  start  location 
Fleet  identifier  for  this  start  location 
Number  of  vehicles  in  the  fleet  for  this 
vehicle  type 

Home  base  node  for  this  fleet  and  vehicle 
type  (a  vehicle  returns  to  its  home  base 
if  not  otherwise  assigned) 

Home  base  facility  for  this  fleet  and 
vehicle  type  {a  vehicle  returns  to  its 

base  if  not  otherwise  assigned) 
day  (hr)  Day  that  this  fleet  and  vehicle  type  are 
first  available 

day  (hr)  Day  that  this  fleet  and  vehicle  type  are 
returned  to  base  with  no  more  use  (blank 
or  0  is  treated  as  available  to  the  end) 
Special  mission  which  restricts  this  fleet 
to  matching  special  mission  movement 
requirements  for  a  designated  time  period 
$/new  veh  Penalty  for  the  first  use  of  a  new  vehicle 
of  this  type  and  fleet 

International  call  sign  of  the  vehicle  or 
ship  or  fleet 

Naval  Intelligence  Security  Code  number  of 
the  vehicle  or  ship  fleet 


Figure  B-l.  Data  Dictionary  Extract  for  the  VehFleet  Table 

The  third  column  is  labeled  as  Domain/Lookup,  meaning  that  it  displays  either  a  domain  or  a  lookup  table.  If  an  upper-case 
lookup  table  name  is  shown,  then  the  field  has  a  lookup,  and  the  domain  is  inherited  from  the  parent  table.  For  example,  the 
first  two  fields  have  a  joint  lookup  into  VehData,  which  means  that  all  Vehicle  Type  and  Vehicle  Identifier  combinations  in 
the  VehFleet  must  match  the  parent  values  in  the  VehData  lookup  table,  and  they  are  text  strings  or  names.  Similarly,  the 
Start  Node  and  Start  Facility  fields  have  a  joint  lookup  to  the  Facility  table.  This  means  that  you  must  create  a  matching  node 
and  facility  in  the  Facility  parent  table  before  you  can  assign  vehicles  to  start  at  that  facility  in  the  VehFleet  table.  The  two 
foreign  key  fields,  Start  Node  and  Start  Facility  in  die  VehFleet  child  table,  must  match  the  parent  key  fields,  Facility  Node 
and  Facility  Name,  for  a  parent  record  in  the  Facility  table.  The  lookup  values  are  always  the  key  fields  of  the  parent  table. 

If  the  third  column  is  not  a  lookup  table,  it  represents  a  domain.  For  example,  the  Vehicle  Fleet  field  has  a  domain  of  A15, 
which  means  any  alphanumeric  text  string  up  to  15  characters  in  length.  TTiis  means  you  are  free  to  give  any  name  you  wish 


Gdas  Algorithm  Description 


l 


Data  Dictionary 


to  the  Vehicle  Fleet  (no  lookups  are  enforced).  Of  course,  preferably  the  name  is  descriptive;  in  the  figure,  the  vehicle  fleet 
names  tend  to  match  the  start  node. 

The  field  Number  of  Vehicles  has  a  Domain  of  Short>=0,  which  means  a  nonnegative  short  integer  (values  between  0  and 
32,767).  Other  typical  numerical  domains  may  incorporate  ranges,  such  as  1,99  or  0,99999  or  0,15.  Additional  ranges 
include  Long+/-  (any  integer),  Double>=0  (any  nonnegative  floating  point  number),  and  reqqn  (a  nonnegative  domain  sized 
for  requirement  quantities). 

The  fourth  column  shown  in  the  Data  Dictionary  is  labeled  Key?  and  displays  a  Y  if  the  field  is  a  key  field.  For  the  VehFleet 
table,  the  first  three  fields  are  key  fields,  as  indicated  in  the  figure.  GDAS  always  lists  key  fields  first  for  each  table. 

The  key  fields  of  a  table  may  themselves  be  lookups.  In  the  example,  the  first  two  key  fields  are  lookups  into  the  parent 
VehData  table,  whereas  the  third  key  field  is  a  domain  consisting  of  any  15  character  alphanumeric  string,  with  no  lookup. 
The  non-key  fields  may  also  be  looloips  or  domains. 

Additional  information  in  the  Data  Dictionary  shows  whether  the  field  is  In  or  Out,  meaning  that  it  is  either  an  input  to  the 
model  or  an  output  from  the  model.  Some  reference  data  is  neither  input  nor  output. 

The  Unit  of  Measure  is  indicated  where  appropriate.  The  Start  Day  Available  field  has  a  unit  of  measure  indicated  by  day 
(hr),  which  means  that  data  input  is  in  whole  days,  but  this  is  converted  to  hours  for  the  hourly  simulation  used  in  the  model 
itself.  In  general,  the  model  performs  all  calculations  in  hours  for  higher  accuracy  in  travel  times  and  load  rates,  and  to  make 
cumulative  differences  in  these  parameters  visible  for  sensitivity  studies.  Realistically,  however,  the  data  inputs  (availability 
day,  required  delivery  day,  earliest  delivery  day,  etc.)  are  not  accurate  even  to  the  nearest  day,  so  database  inputs  and  outputs 
are  typically  stored  in  days  rather  than  hours. 

Finally,  a  description  of  the  field  is  provided.  All  of  this  information  is  available  on-line,  while  editing  the  tables,  by  pressing 
the  F10  Menu  key,  then  selecting  Help/Data. 
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Directory  Type :  Reference 


MEASCLAS 
Measure  Class 


#  K?  Field  Name 

_ I _ 

1  Y  Measure  Class 


2  Description 


Edit  Limits  Defines  the  measurement  classes  (e.g.  Cargo  Quantity,  Max  Cargo  Item  Dimension,  Vehicles 
Constant  No  Per  Day,  MOG  or  #  Berths,  Vehicle  Dimension,  etc.)  _ 


Model  Datatype 


Domain  I  Lookup  B|V  Unit  Meas  Description 
j _ _ I  ,  '  ,1 _ l - 


A15  Measure  claj 


Measure  class  defining  the  area  of 
applicability  of  different  measures  (e.g.. 
Cargo  Quantity,  Dimension  Limit, 
Vehicles/Day,  Max  Vehicles,  Throughput, 
Storage) 

General  description  of  the  measure  class 


MODELRPT 

Edit  Limits 

Allows  the  user  to  specifiy  which  reports  to  generate  from  model  outputs 

Model  Report 

Constant  No 

#  K?  Field  Name 

i  i 


1  Y  Report  Table 

2  Report  Table  Description 


Model  Datatype _  ^DomainlLookup^BlV^Unit  Meas  Description 


TABLE  Lists  the  ci 


Lists  the  custom  report  tables  that  have 
queries  to  be  generated  after  the  model  has 
been  executed 

Description  of  the  Custom  report  table 


REJTYPE 
Rejection  Type 


#  K?  Field  Name 

I  I 


1  Y  Rejection  Type 

2  Description 


SCHEDTYP 
Scheduling  Type 


#  K?  Field  Name 


Edit  Limits  Lists  the  available  delay  reason  types 
Constant  No 


Model  Datatype 


Domain | Lookup B | V  Unit  Meas  Description 


Rejection  reason  type 
Description  of  the  rejection  type 


Edit  Limits  Lists  the  scheduling  model  algorithm  types 
Constant  No 


Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 


1  Y  Scheduling  Model  Type 

2  Level  of  Detail 

3  Description 


Scheduling  model  algorithm  type 
Level  of  detail  for  the  scheduling 
algorithm 

Brief  description  of  the  scheduling 
algorithm 


VARYDIST  Edit  Limits  Stochastic  or  parametric  distribution  types  for  sampling  data 

Vary  Distribution  Constant  No 


#  K?  Field  Name 


1  Y  Distribution  Type 


Model  Datatype  Domain | Lookup  B|V  Unit  Meas  Description 


A15  Stochastic  data  sampling  distribution  type 


VARYPARD  Edit  Limits  Kists  allowable  tables  and  data  fields  for  users  to  vary  either  parametrically  or  as 

Vary  Parametric  Data  Constant  No  time  variations 


#  K?  Field  Name 

I  I 


1  Y  Table  to  Vary 

2  Y  Field  to  Vary 

3  Description 


Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 


A8  Table  name  which  can  be  varied 
A25  Field  name  which  can  be  varied 
A255  Data  field  description 


Edit  Limits  Lists  the  allowable  tables  and  fields  which  can  be  saved  over  multiple  parametric  or 


Vary  Storable  Data  Constant  No  stochastic  runs 


#  K?  Field  Name 

I _ I - 

1  Y  Table  to  Save 

2  Y  Field  to  Save 

3  Description 


^ Model  Datatype _ ^ Domain  |  Lookup  ( B 1 V ^  Unit  Meas  Description 

A8  Table  name  1 

over  mult ip 

A25  Nonkey  data 

sensitivity 

A255  Data  field  < 


Table  name  which  has  data  that  can  be  saved 

over  multiple  sensitivity  runs 

Nonkey  data  element  which  can  be  saved  over 

sensitivity  sampling  runs 

Data  field  description 
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Directory  Type:  Scenario 


AGENTLEG  Edit  Limits  Selects  the  standard  routes  for  each  agent  for  map  display 

Agent  Route  Mapping 


#  K?  Field  Name 


1  Y  From  Node 

2  Y  To  Node 

3  Y  Transport  Agent 

4  Y  Planning  Fleet 

5  Standard  Depart  Interval 


Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 


NODE  From  node  e 

world  map  d 

NODE  To  node  ext 

world  map  d 

A15  Transport  at 


PLANFLT 
Short >=1 


From  node  extracted  from  STDSTOP  for  the 
world  map  display 

To  node  extracted  from  STDSTOP  for  the 
world  map  display 

Transportation  agent  or  company  identifier 
for  the  fleet 

Standard  prescheduled  route  identifier 
Standard  depart  time  interval  for  a 
prescheduled  route 


BASMEAS 

Edit  Limits 

Basic  Measure 

#  K?  Field  Name  Model  Datatype 

I _ l - - - 1 - 

1  Y  Basic  Quantity  Measure  basemeas 

2  baseqnreq 


baseqnreq 

baseqndel 


cargo  class  has  a  basic  measure  used  for  quantity  splits 


'  Datatype  Domain] Lookup ^BlV^Unit  Meas  Description 

teas  MEASURE  Basic  unit  < 

quantities 

[nreq  Long>=0  Q  Basic  quanii 


Long>=0 


Basic  unit  of  measure  for  reporting  cargo 
quantities  (ston,  cbbl,  pax) 

Basic  quanity  required  accumulated  for 
closure  calculations  for  the  current  major 
unit 

Basic  quanity  delivered  accumulated  for 
closure  calculations  for  the  current  major 
unit 


CARGCLAS 

Edit  Limits 

Cargo  Class 

measures  are  applicable  to  each  cargo  category  and  cargo  type 


#  K?  Field  Name  Model  Datatype 

i  i  i _ 


1  Y  Cargo  Class 

2  Basic  Quantity  Measure 

3  Pounds  Per  Basic  Quantity  lbsperqn 

4  Has  Accompanying  Pounds?  hasaccomplbs 


Domain ( Lookup  BlV  Unit  Meas  Description 
J _ 1 -  11 - 1 - 

A15  Cargo  class  {Dry,  Pax,  POL)  which  defines 

dimensional  measures  for  cargo 

BASMEAS  Yes  Basic  unit  of  measure  for  reporting 

quantity  of  this  cargo  class  (ston,  pax, 
cbbl) 

Long>=0  Yes  lbs/Q  Pounds  per  unit  basic  quantity  in  the  basic 

unit  of  measure,  used  for  conversion  to 
accumulate  short  ton  weight  totals  for 
vehicle  loading  or  facility  throughput 

Yesflag  Yes  if  theater -dependent  accompanying 

pounds  per  unit  basic  quantity  are  obtained 
from  the  THTRREQ  table  rather  than  a 
conversion  factor  (otherwise  Pounds  Per 
Basic  Quantity  field  is  used) 

Yesflag  Yes  if  the  cargo  class  represents 

passengers,  used  to  compute  closure  based 
on  the  MAJUNIT  %  closure  criteria 

MEASURE  Basic  unit  of  measure  record  number  in  the 

MEASURE  table 

CLASMEAS  First  measure  associated  with  this  cargo 

class 

0,99  Offset  of  the  basic  quantity  measure 

relative  to  the  first  quantity  measure  of 
this  cargo  class 


basmeas 
f irstclasmeas 
basqnoffset 


CARGCONF 

Cargo  Configuration 


Edit  Limits  Lists  the  cargo  configurations  used  to  containerize,  package,  or  modify  cargo  for 
transport,  and  sets  the  time  rate  for  configuration 


#  K?  Field  Name 


1  Y  Cargo  Configuration 

2  Configuration  Rate 

3  De configuration  Rate 


Model  Datatype 


cfgrt 

uncfgrt 


Domain | Lookup  B|V  Unit  Meas  Description 


A15  Cargo  confi< 


Short >=0 
Short >-0 


Cargo  configuration  which  is  used  to 
package  the  cargo  for  transport  on  one  or 
more  modes 

Rate  at  which  cargo  can  be  configured  when 
changing  configuration 
Rate  at  which  cargo  can  first  be  un¬ 
configured  when  changing  configuration 


Edit  Limits  Lists  cargo  derived  from  a  single  movement  requirement  and  cargo  category,  which  is 

Output  loaded  on  a  single  trip,  vehicle,  and  compartment 


#  K?  Field  Name 
1  1 


1  Y  Cargo  Number 

2  Requirement  Id 

3  Cargo  Category 

4  Cargo  Configuration 


Cargo  Type 
Load  Stop  Number 


Unload  Stop  Number 


Model  Datatype  Domain | Lookup  B|V  Unit  Meas  Description 


crgreq 

crgcat 


crgcfg 


crgtyp 

ldstp 


uldstp 


Record#  BigSt 
REQUIRE 
CARGO CAT 


CARGTYPE 

STOP 


Cargo  or  shipment  number 

Requirement  identifier  for  this  cargo 

Cargo  category  which  describes  the  kind  of 

cargo  being  transported 

Cargo  configuration  which  is  used  to 

package  the  cargo  for  transport  on  one  or 

more  modes 

Cargo  type  for  this  cargo 
Load  stop  number  for  this  cargo  (in  the 
model  after  planning  prior  to  scheduling, 
this  is  the  node  number) 

Unload  stop  number  for  this  cargo  (in  the 
model  after  planning  prior  to  scheduling. 
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Directory  Type:  Scenario 


CARGO 

Cargo 


Edit  Limits 
Output 


Lists  cargo  derived  from  a  single  movement  requirement  and  cargo  category,  which  is 
loaded  on  a  single  trip,  vehicle,  and  compartment  _ 


1 - 

i  K? 

( Field  Name 

Model  Datatype 

i 

Domain | Lookup  ^  B | V ( Unit  Meas 

8 

Cargo  Basic  Quantity 

crgqn 

reqqn 

Q 

9 

Compartment  Type 

crgcpt 

CPTTYPE 

10 

Begin  Load  Day 

begld 

DayToHr 

day  (hr) 

11 

End  Load  Day 

end  Id 

DayToHr 

day  (hr) 

12 

Begin  Unload  Day 

beguld 

DayToHr 

day  (hr) 

13 

End  Unload  Day 

enduld 

DayToHr 

day  (hr) 

14 

Is  Attritted? 

iscrgattr 

Yesflag 

15 

Attrit  Probability  %% 

crgattrprob 

0,9999 

%% 

16 

Cargo  Predecessor 

crgpred 

CARGO 

17 

Planning  Fleet 

planning_fleet 

PLANFLT 

18 

Is  Final? 

isfinal 

Yesflag 

19 

Order  Number 

cargo_order 

Long>=0 

20 

nextcrgld 

CARGO 

21 

nextcrguld 

CARGO 

22 

ergs tat us 

0,9 

23 

listcrgsucc 

CARGO 

24 

nextcrgsucc 

CARGO 

25 

ergdue 

DayToHr 

hr 

26 

iscrgreplanned 

Yesflag 

27 

nextergonboard 

CARGO 

28 

quan_unloaded 

reqqn 

29 

quan_re loaded 

reqqn 

30 

load_delay 

HoursDelay 

hr 

31 

unld_delay 

HoursDelay 

hr 

32 

time__to_go 

HoursDelay 

hr 

33 

nextmlistcargo 

CARGO 

34 

cargo__cbr 

Long+/- 

$/Q 

35 

is_resupply_pattem 

Boolean 

36 

nextsupstorecargo 

CARGO 

Description 
J - 


this  is  the  node  number) 

Cargo  quantity  in  the  basic  unit  of  measure 
for  its  cargo  class  (ston,  pax,  cbbl) 
Vehicle  compartment  into  which  this  cargo 
was  loaded 

Day  that  the  cargo  begins  loading  (in  the 
model  prior  to  simulation,  this  is  the 
earliest  possible  load  time  based  on  RLD  or 
predecessor  cargo  or  earliest  theater 
depart  minus  10) 

Day  that  the  cargo  completes  loading  (in 
the  model  prior  to  simulation  this  is  the 
target  lift  time  or  planned  begin  load 
time) 

Day  that  the  cargo  begins  offloading  (in 
the  model  prior  to  simulation,  this  is  also 
the  earliest  possible  unload  time  based  on 
EDD  for  final  destination  cargos) 

Day  that  the  cargo  is  scheduled  to  complete 
offloading  (this  is  updated  during 
planning,  scheduling,  and  simulation) 

Yes  if  the  cargo  is  attritted  in  the  last 
run  results,  blank  otherwise 
Calculated  cumulative  probability  of 
attrition  (in  %%  or  ten  thousandths)  for 
the  cargo  based  on  its  route  and  schedule 
and  including  the  probability  of  attrition 
of  prior  cargos 

Unique  predecessor  cargo  which  immediately 
precedes  this  cargo  and  carries  the  same 
requirement  (zero  for  an  origin  cargo) 
Planning  fleet  selected  by  mode  planning  to 
move  the  cargo 

Yes  if  the  cargo  is  a  final  leg  to  the 
requirement  ultimate  destination 
An  order  number  that  is  assigned  if  the 
cargo  is  a  resupply  record,  matching  an 
order  in  RPTSUPST 

After  scheduling,  next  cargo  at  the  same 
load  stop;  before  scheduling,  next  cargo 
planned  at  the  same  POE  node;  after 
rejection,  next  cargo  rejected;  each  cargo 
is  always  on  1  of  3  lists: 

LISTnodecrg (poenode) ,  LISTcrg(poestop) ,  or 
LISTcrgreject 

Next  cargo  at  the  same  unload  stop  after 
scheduling 

Cargo  status:  WAITING= waiting  for 
scheduling;  REJECTED-rejected  either  in 
planning  (crgtyp=0)  or  in  scheduling 
(crgtyp>0) ;  SCHEDULED*scheduled  but  not  yet 
simulated;  POES IM= loading  at  POE  began 
simulation;  PODS IM=unloading  at  POD  began 
simulation 

List  of  successor  cargos  which  immediately 
follow  this  predecessor  cargo  and  which 
carry  the  same  requirement 
Next  successor  cargo  with  the  same 
predecessor  cargo 

Planned  time  that  the  cargo  is  due  to  be 
delivered 

Yes  if  the  cargo  previously  failed 
scheduling  and  was  replanned 
Next  pointer  for  LISTcrgonboard  and 
LISTcrgclose  in  final  closure  and  attrition 
Basic  quantity  unloaded  used  for  tracking 
simultaneous  unload  and  load 
Basic  quantity  of  a  succesor  of  this  cargo 
onloaded  used  for  tracking  simultaneous 
load  and  unload 

Hours  of  loading  delay  due  to  facility 
througput  capacity 

Hours  of  unloading  delay  due  to  facility 
throughput  capacity 

Estimated  hours  of  travel  to  reach  the 
requirement  destination 

Next  pointer  for  the  multicriteria  list  of 

cargos  ready  for  scheduling 

Cargo  cost  benefit  ratio  for  sorting  the 

greedy  vehicle  list  of  cargos 

Flag  to  identify  representative  resupply 

cargos 

Next  pointer  for  when  the  cargo  is 
representative  for  a  supply  storage  node 
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Directory  Type :  Scenario 


CARGOCAT 
Cargo  Category 

K?  Field  Name 

i  _ 

1  Y  Cargo  Category 

2  Cargo  Class 

3  Category  Code 


Edit  Limits  Lists  the  cargo  categories  which  specifies  the  kind  of  cargo  at  the  most  detailed  level, 
often  based  on  JOPES  three-position  cargo  category  plus  heavy  lift  code 


Model  Datatype _ Domain | Lookup [V^Unit  Meas  ^ Description 

A15  Cargo  categ* 


CARGTYPE 
Cargo  Type 

#  K?  Field  Name 
l _ l - 

1  Y  Cargo  Type 


Cargo  Class 
Transport  Mode 
Cargo  Type  Description 


A15  Cargo  category  which  describes  the  kind  of 

cargo  being  transported 

catclas  CARGCLAS  Yes  Cargo  class  (Dry,  Pax,  POL)  which  defines 

dimensional  measures  for  this  cargo 
category 

A4  Four  position  JOPES  cargo  category  code 

including  heavy  lift  code  (AO=vehicle  NAT, 
B0*NSDA  NAT,  B1=NSDA  outsize,  B2C=NSDA 
oversize  noncont,  etc.) 

rrement  cat  rain  split  size  Long>=l  Yes  Q  Discrete  size  increment  for  loading  this 

—  ~  cargo,  expressed  m  the  basic  unit  of 

measure;  if  specified,  a  split  cargo  must 
be  an  integer  multiple  of  the  size 
increment 

Origin  configorig  CARGCONF  Yes  Starting  cargo  configuration  at  the  origin 

for  this  cargo  category 

cat  is  ammo  Yesflag  Yes  if  the  cargo  category  is  treated  as 

—  —  hazardous  ammunition  in  route  sequence, 

i.e.  it  is  constrained  to  be  last  on  and 
first  off  in  multi -port  routes 

AlOO  Description  of  the  cargo  category 

firstcatmeas  CATMEAS  First  measure  for  this  cargo  category  in 

the  CATMEAS  table 

listexcrgcat  EXCLUDE  List  of  exclusions  for  this  cargo  category, 

if  any 

firstsupstore  SUPSTORE  First  supply  theater  record  for  this  cargo 

category 

Edit  Limits  Lists  the  cargo  types,  which  define  kinds  of  cargo  affecting  stow  factors,  load  rates, 

and  load  compatibility  for  a  specific  mode  of  transport  _ 


4 

Discrete  Load  Increment 

cat_min_split_size 

Long>=l 

5 

Configuration  at  Origin 

configorig 

CARGCONF 

6 

Is  Ammunition? 

cat_is_ammo 

Yesflag 

7 

8 

Description 

firstcatmeas 

AlOO 

CATMEAS 

9 

listexcrgcat 

EXCLUDE 

10 

firstsupstore 

SUPSTORE 

Model  Datatype 


crgtypclas 

crgmod 

liststowpen 

crgtypoffset 


Domain! Lookup  B|V  Unit  Meas  Description 

J - ! - 1 - 1 - 1 - 

A15  Mode-specif: 


CARGCLAS 

MODE 


AlOO 

STOWPEN 


Mode- specific  cargo  type  which  groups  cargo 
categories  for  a  given  transport  mode  in 
order  to  define  stow  factors,  load  rates, 
and  load  compatibility  for  vehicle 
compartments 

Cargo  class  (Dry,  Pax,  POL)  which  defines 
dimensional  measures  for  this  cargo  type 
Transport  mode  associated  with  this  mode- 
specific  cargo  type 

Description  of  the  mode-specific  cargo  type 
List  of  STOWPEN  records  and  associated 
compartment  types  in  preferred  order  for 
this  cargo  type 

Cargo  type  offset  within  its  mode  of 
transport  for  direct  access  of  stow  factors 
and  stow  penalties 


CATMEAS 

Category  Measure 


#  K?  Field  Name 


1  Y  Cargo  Category 

2  Y  Cargo  Measure 


Edit  Limits  Lists  the  dimensional  measures  applicable  to  each  cargo  category;  generated 
Display  Onl  automatically  from  the  CLASMEAS  table  to  provide  a  lookup  for  REQQUAN  quantities 


Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 


CARGOCAT  Cargo  categi 

cargo  being 

MEASURE  Name  of  a  m< 


catmeascat  CARGOCAT  Cargo  category  which  describes  the  kind  of 

cargo  being  transported 

catmeasmeas  MEASURE  Name  of  a  measure  (basic  or  nonbasic)  for 

specifying  cargo  quantity  or  dimensions 

Edit  Limits  i  Lists  the  conversion  of  cargo  categories  to  mode-specific  cargo  types  which  define  stow 


Cargo  Category  Mode  Keys  Full 


factors  and  load  rates  for  each  vehicle  type 


#  K?  Field  Name 


1  Y  Transport  Mode 

2  Y  Cargo  Category 

3  Y  Cargo  Configuration 

4  Cargo  Type 


Model  Datatype 


Domain  |  Lookup  B  |  V  Unit  Meas  Description 


CARGCONF 

CARGTYPE 


CLASMEAS 

Cargo  Class  Measure 


#  K?  Field  Name 


1  Y  Cargo  Class 

2  Y  Cargo  Measure 


MODE  Transport  mode 

CARGOCAT  Cargo  category  which  describes  the  kind  of 

cargo  being  transported 

^on  CARGCONF  Cargo  configuration  status 

catmodcrgtyp  CARGTYPE  Cargo  type  used  to  represent  this  cargo 

category  and  configuration  for  the 
specified  transport  mode  (leave  cargo  type 
blank  if  the  transport  mode  cannot  carry 
the  category  or  configuration,  e.g.  NSDA 
via  Airlift) 


Edit  Limits  Lists  the  major  classes  of  cargo  and  what  quantity  measures  are  applicable 


Model  Datatype  ( Domain [ Lookup^] V^nit  Meas  description 


cclasmeas 


CARGCLAS  Cargo  class 

associated  i 

MEASURE  Type  of  meaj 


Cargo  class  (Dry,  Pax,  POL)  which  is 
associated  with  specific  quantity  measures 
Type  of  measure  used  for  specifying 
quantity  of  cargos  in  this  cargo  class 
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Directory  Type :  Scenario 


CONSRATE 

Edit  Limits 

Consumption  Rate 

Output 

#  K?  Field  Name  Model  Datatype 


1  Y  Unit  Destination 

2  Y  Consumed  Cargo  Category  supstore__record 

3  Supply  Storage  Node 

4  consumption_rate 

5  consumed_cargocat 


Domain  |  Lookup  ^  B  [  V  ^  Unit  Meas  description 


NODE  Destination 

that  consume 

SUPSTORE  Supply  cargi 


SUPSTORE 

Long>-0 


Destination  node  for  a  requirement  type 
that  consumes  resupply 

Supply  cargo  type  that  is  consumed  by  other 

requirements  at  their  destination 

Supply  storage  node  or  terminal 

Total  current  consumption  rate  for  all 

requirement  types  consumming  the  supply 

type  at  this  destination 

Cargo  category  consumed 


CONVOY 

Convoy 


Edit  Limits  Specifies  information  about  convoy  routes  which  are  to  be  used  for  sealift  when 
traveling  between  the  assembly  node  theater  and  the  disassembly  node  theater 


#  K?  Field  Name 
1  Y  Convoy  Assembly  Node 


Model  Datatype 

j - 

cnvyassfac 


Domain  I  Lookup  B|V  Unit  Meas  Description 
j _ ! _ i  -l—i - 1 - 

FACILITY  Assembly  no* 


2  Y  Assembly  Facility 

3  Y  Convoy  Disassembly  Node  cnvydisfac 

4  Y  Disassembly  Facility 


FACILITY 

FACILITY 


5 

Convoy  Route  Type 

cnvyrouttype 

ROUTTYPE 

Yes 

6 

Convoy  Vehicle  Per  Escort 

escortships 

1,999 

Yes 

7 

Convoy  Speed 

cnvyspeed 

1,999 

Yes 

nmi/hr 

8 

Convoy  Delay  Hours 

cnvydel 

HoursDelay 

hr 

9 

Convoy  Interval  Days 

cnvyinterval 

DaysDelayToHr  Yes 

day 

10 

Convoy  Min  Vehicles 

cnvyminships 

0,999 

11 

Convoy  Max  Vehicles 

cnvymaxships 

0,999 

12 

Max  Vehicle  Wait  Days 

cnvymaxwait 

DaysDelayToHr 

day 

13 

Link  Attrit  Multiplier  % 

cnvylinkattrmult 

% 

% 

14 

Node  Attrit  Multiplier  % 

cnvynodeat t rmul t 

% 

% 

15 

cnvyattr 

Short >«0 

%% 

16 

envytime 

HoursDelay 

hr 

17 

listenvytrip 

TRIP 

18 

cnvylastsent 

CONVTRIP 

19 

envybuildup 

CONVTRIP 

Assembly  node  for  ships  and  escorts  on  this 
convoy  route  {normally  in  the  origin 
theater) 

Assembly  facility  for  ships  and  escorts  on 
this  convoy  route 

Final  disassembly  node  for  ships  and 
escorts  on  this  convoy  route  (normally  in 
the  destination  theater) 

Final  disassembly  facility  for  ships  and 
escorts  on  this  convoy  route 
Convoy  route  type  which  can  accomodate  all 
ships  in  the  convoy 

Number  of  ships  handled  by  each  escort 
{used  to  compute  the  number  of  escorts) 
Speed  at  which  all  convoy  ships  travel  on 
this  convoy  route ,  in  nautical  mph 
Additional  convoy  transit  delay  time  in 
hours  for  management  operations, 
diversions,  assembly  and  disassembly 
operations,  etc.  after  the  convoy  assembly 
day  and  before  the  convoy  disassembly 
Minimum  time  interval  in  days  between 
scheduled  convoy  departures 
Minimum  number  of  ships  permitted  in  a 
convoy  trip 

Maximum  number  of  ships  permitted  in  a 
convoy  trip 

Maximum  ship  waiting  time  to  assemble  a 
minimum  size  convoy  beyond  which  the  ship 
sails  independently 

Convoy  link  attrition  multiplier  for  ships 
in  this  convoy 

Convoy  node  attrition  multiplier  for  ships 
in  this  convoy 

Precomputed  discrete  attrition  for  a  convoy 
from  assembly  to  disassembly  including  both 
node  and  link  attrition  factors 
Precomputed  convoy  travel  time  from 
assembly  to  disassembly  including  link 
delays,  link  distances  at  convoy  speed,  and 
additional  convoy  delay  time 
List  of  trips  in  the  next  convoy  trip 
currently  being  assembled 

Last  convoy  trip  scheduled  for  departure  at 
this  convoy  location 

Current  convoy  trip  being  accumulated  prior 
to  reaching  the  minimum  size  and  being 
scheduled  for  departure 


CONVTRIP 

Edit  Limits 

Stores  information  about  convoy  trips 

Convoy  Trip 

Output 

#  K?  Field  Name 

a  I 


1  Y  Convoy  Trip  Number 

2  Convoy  Assembly  Node 

3  Assembly  Facility 

4  Convoy  Disassembly  Node 

5  Disassembly  Facility 

6  Convoy  Assembly  Day 

7  Convoy  Disassembly  Day 

8  Convoy  Size 

9  Number  of  Escorts 


Model  Datatype 


Domain | Lookup  B|v  Unit  Meas  Description 


cnvyadep 

cnvyddep 

cnvysize 

cnvyescrts 


Record#  Vehic 
CONVOY 
CONVOY 
CONVOY 

CONVOY 

DayToHr 

DayToHr 


day  (hr) 
day  (hr) 


Convoy  trip  number 

Assembly  node  for  this  convoy  trip 

Assembly  facility  for  this  convoy  trip 

Final  disassembly  node  for  ships  and 

escorts  on  this  convoy  trip 

Final  disassembly  facility  for  ships  and 

escorts  on  this  convoy  trip 

Depart  day  of  the  convoy  at  the  assembly 

point 

Depart  day  of  the  ships  in  the  convoy  at 
the  disassembly  point 
Number  of  ships  in  the  convoy 
Number  of  escorts  in  the  convoy 
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Directory  Type :  Scenario 


CPTMEAS  Edit  Limits  Lists  the  measures  for  defining  compartment  capacity 

Compartment  Measure 


#  K?  Field  Name 

i 


1  Y  Compartment  Type 

2  Y  Compartment  Measure 


Model  Datatype  ^  Domain  |  Lookup  ^  B  |  V  ^  Unit  Meas  Description 


CPTTYPE  Compartment 


cpttype 

Compartment  Type 


#  K?  Field  Name 


1  Y  Compartment  Type 


f irststowfact  STOWFACT 


Edit  Limits  Defines  vehicle  compartment  types 


Model  Datatype  Domain | Lookup  B|V 


Compartment  type  name  used  to  specify  stow 
factors  for  vehicle  types  and  capacities 
for  vehicles 

Unit  of  measure  for  defining  compartment 
capacity  (in  addition  to  the  total  ston 
measure  which  is  always  used  for  each 
vehicle) 

First  stow  factor  for  this  compartment  type 
and  measure 


Domain | Lookup  B|V  Unit  Meas  Description 


A15  Generic  compartment  type  name  which  is 

associated  with  stow  factors  and  vehicle 
capacities  (e.g..  Hold  for  ships.  Outsize 
for  aircraft,  Boxcar  for  rail.  Flatbed  for 
motor) 

cptmod  MODE  Yes  Transport  mode  associated  with  this 

compartment  type 

firstcptmeas  CPTMEAS  First  compartment  measure  for  defining 

compartment  capacity 

cptldqn  reqqn  Q  Cargo  quantity  which  could  be  loaded  on 

each  compartment  for  the  current  insertion 
cargo 

cptbestqn  reqqn  Q  Quantity  of  the  best  cargo  so  far  which  can 

*  be  loaded  on  each  compartment 

firststowpen  STOWPEN  First  stow  penalty  record  for  this 

compartment  type 

Edit  Limits  Sets  user-definable  exclusions  for  cargo  loading,  based  on  various  combinations  of 

factors  such  as  Mode,  Vehicle  Type,  Cargo  Category,  Planning  Fleet,  Node,  Theater,  and 


EXCLUDE 

Exclusion 


#  K?  Field  Name 

l _ I - 

1  Y  Exclusion  Label 


2  Transport  Mode 

cptmod 

MODE 

Yes 

3 

firstcptmeas 

CPTMEAS 

4 

cptldqn 

reqqn 

Q 

5 

cptbestqn 

reqqn 

Q 

6 

firststowpen 

STOWPEN 

Model  Datatype  Domain | Lookup  B|V  Unit  Meas  Description 

j - 1 - 1 - 1 - 1 - 

A15  Label  for  a 


Node  Excluded  for  Loading  exnode 


FACCAP 

Facility  Capacity 


#  K?  Field  Name 


A15  Label  for  a  user-defined  combination  of 

factors  to  exclude  cargo  loading  at  POEs 
and  unloading  at  PODs 

:  Loading  exnode  NODE  Excluded  node  for  loading  and  offloading, 

if  any  (blank  if  not  applicable,  i.e.,  this 
exclusion  applies  to  all  nodes  and  is 
independent  of  node) 

:luded  exfactyp  FACTYPE  Excluded  facility  type  for  loading  and 

offloading,  if  any  (blank  if  not 
applicable,  i.e.  exclusion  record  applies 
to  all  facility  types  or  is  independent  of 
facility  type) 

Excluded  exreqtyp  REQTYPE  Excluded  requirement  type,  if  any  (blank  if 

not  applicable) 

Luded  exvehtyp  VEHTYPE  Excluded  vehicle  type,  if  any  (blank  if  not 

applicable) 

ccluded  exfleet  PLANFLT  Excluded  planning  fleet,  if  any  (blank  if 

not  applicable ) 

exthtr  THEATER  Excluded  theater,  if  any  (blank  if  not 

applicable) 

ccluded  excrgcat  CARGOCAT  Excluded  cargo  category,  if  any  (blank  if 

not  applicable) 

exmode  MODE  Excluded  transport  mode,  if  any  (blank  if 

not  applicable) 

excount  0,7  Computed  count  of  nonzero  secondary  fields 

in  this  exclusion  record  (each  exclusion 
has  at  least  one  nonzero  primary  field) 

nextexnode  EXCLUDE  Next  exclusion  for  the  same  node 

nextexfactyp  EXCLUDE  Next  exclusion  for  the  same  facility 

next  exreqtyp  EXCLUDE  Next  exclusion  for  the  same  requirement 

type 

next  exvehtyp  EXCLUDE  Next  exclusion  for  the  same  vehicle  type 

nextexfleet  EXCLUDE  Next  exclusion  for  the  same  fleet 

next exthtr  EXCLUDE  Next  exclusion  for  the  same  theater 

next excrgcat  EXCLUDE  Next  exclusion  for  the  same  cargo  category 

nextexmode  EXCLUDE  Next  exclusion  for  the  same  mode 

Edit  Limits  Specifies  facility  limits  and  constraints  on  cargo  throughput  for  different  facility 
measures 


3 

Facility  Type  Excluded 

exfactyp 

FACTYPE 

4 

Requirement  Type  Excluded 

exreqtyp 

REQTYPE 

5 

Vehicle  Type  Excluded 

exvehtyp 

VEHTYPE 

6 

Planning  Fleet  Excluded 

exfleet 

PLANFLT 

7 

Theater  Excluded 

exthtr 

THEATER 

8 

Cargo  Category  Excluded 

excrgcat 

CARGOCAT 

9 

Mode  Excluded 

exmode 

MODE 

10 

excount 

0,7 

11 

nextexnode 

EXCLUDE 

12 

nextexfactyp 

EXCLUDE 

13 

next exreqtyp 

EXCLUDE 

14 

next exvehtyp 

EXCLUDE 

15 

nextexfleet 

EXCLUDE 

16 

next exthtr 

EXCLUDE 

17 

nextexcrgcat 

EXCLUDE 

18 

nextexmode 

EXCLUDE 

Model  Datatype 


Domain | Lookup  B|v  Unit  Meas  Description 


1  Y  Facility  Node 

2  Y  Facility  Name 

3  Y  Facility  Capacity  Measure  facmeas 


Facility  Capacity 


faccap 


FACILITY 

FACILITY 

MEASURE 

faccap 


Node  with  one  or  more  facilities 
Facility  name  at  this  node 
Cargo  storage  or  throughput  handling 
capacity  measure  for  this  facility 
Q  or  Q/hr  Hourly  rate  or  total  storage  cargo  handling 
capacity  for  this  measure  and  facility  at 
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Directory  Type:  Scenario 


FACCAP 

Facility  Capacity 
#  K?  Field  Name 


Edit  Limits  Specifies  facility  limits  and  constraints  on  cargo  throughput  for  different  facility 
measures  _ 


Model  Datatype 

faccapstor 

faccapsathrs 


Domain | Lookup  B|V  Unit  Meas  Description 


faccap 

HoursDelay 


the  node 

Remaining  storage  capacity  if  the  measure 
is  storage 

Start  hour  on  the  current  day  when  this 
facility  storage  capacity  measure  became 
saturated  (0  if  unsaturated) 


FACILITY  Edit 

Facility 


#  K?  Field  Name 
l _ 1 - 

1  Y  Node 

2  Y  Facility  Name 

3  Facility  Type 

4  Max  Vehicles  Per  Hour 


Edit  Limits  Lists  port  facilities  at  nodes 


Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 


NODE 

A15 

FACTYPE 

facvph 


veh/hr 


FACTYPE 
Facility  Type 

#  K?  Field  Name 


1  Y  Facility  Type 

2  Transport  Mode 


facnode  NODE  Node  with  one  or  more  facilities 

Facility  name  at  this  node 

factyp  FACTYPE  Yes  Facility  type  for  this  facility 

Hour  facvph  facvph  veh/hr  Number  of  combined  vehicle  arrivals  and 

departures  which  can  be  handled  per  hour  m 
this  facility  during  its  hours  of  operation 

facDark  Short >=0  veh  Maximum  number  of  "standard"  vehicles 

F  permitted  in  the  facility  at  the  same  time, 

e.g.  working  MOG  for  airlift  or  number  of 
berths  for  sealift  (vehicle  types  are 
weighted  by  an  effective  factor  to  convert 
to  a  standard  vehicle)  (model  scales  by  100 
to  %) 

>av  fachpd  0,24  hr/day  Operating  hours  per  day  that  the  facility 

x  is  open 

faclen  Short>=0  ft  Maximum  length  available  (e.g.,  runway 

length  for  air,  berth  length  for  sea) 

facwid  0,999  ft  Maximum  width  available  (e.g.,  runway  width 

for  air,  berth  beam  for  sea) 

facdim  0,999  varies  Maximum  vehicle  dimension  allowed  in  the 

>n  racaim  '  facility,  a  user-definable  criterion,  such 

as  draft  for  sealift 

facratina  Short>=0  varies  Facility  rating  which  limits  the  maximum 

allowable  vehicle  rating,  based  on  a  user- 
definable  critieria  (e.g.,  load 
classification  number  for  air,  boom 
capacity  or  sea) 

facvphused  facvph  veh/hr  Number  of  arrivals  and  departures  used  up 

at  the  facility  for  the  current  hour 

firstfaccap  FACCAP  First  facility  measure  constraint  for  this 

facility 

fachrptr  FACCAPHR  First  record  in  the  FACCAPHR  table,  if  any, 

*  "  for  this  facility  on  the  current  simulation 

day 

facstoroffset  MEASURE  Offset  for  the  first  FACCAP  record  for 

storage  relative  to  the  first  record 

facthrupoffset  MEASURE  Offset  for  the  first  FACCAP  record  for 

throughput  relative  to  the  first  record 

facoarkusedDc  Lonq>=0  %  Number  of  "standard"  vehicle  parking  spaces 

F  used  in  the  facility  for  the  current 

facility  hour,  expressed  in  percent 

faccurtime  Time  Last  simulation  transaction  time  for  this 

facility 

cur rot f veh  RPTFVEH  Last  RptFVeh  report  record  tracking  vehicle 

throughput  for  this  facility 

isfacinuse  Yesflag  True  if  the  facility  is  in  use  for  vehicle 

flow  simulation 

listfacevent  FACEVENT  Pointer  to  the  list  of  events  for  this 

facility  in  deposition  order 

predfacevent  FACEVENT  Pointer  to  the  last  begin  pred  used  by  the 

subtract  capacity  function 

Edit  Limits  Lists  the  available  facility  or  berth  types  which  are  used  to  define  load  rates  at  port 
facilities 


5 

Max  Parking 

facpark 

Short >=0 

veh 

6 

Operating  Hours /Day 

fachpd 

0,24 

hr/day 

7 

Facility  Length 

faclen 

Short >=0 

ft 

8 

Facility  Width 

facwid 

0,999 

ft 

9 

Facility  Dimension 

facdim 

0,999 

varies 

10 

Facility  Rating 

f aerating 

Short >=0 

varies 

11 

facvphused 

facvph 

veh/hr 

12 

firstfaccap 

FACCAP 

13 

fachrptr 

FACCAPHR 

14 

facstoroffset 

MEASURE 

15 

facthrupoffset 

MEASURE 

16 

faeparkusedpe 

Long>=0 

% 

17 

faccurtime 

Time 

18 

currptfveh 

RPTFVEH 

19 

isfacinuse 

Yesflag 

20 

listfacevent 

FACEVENT 

21 

predfacevent 

FACEVENT 

Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 


listexfactyp 

factypoffset 


Facility  or  berth  type  name  for  airports  or 
seaports  or  other  mode  facilities  (e.g. 
Container  Ammo  for  sealift,  or  Airport  Wide 
Body  for  airlift) 

Transport  mode  for  this  facility  or  berth 
type 

List  of  exclusions  or  constraints  for  this 
facility  type,  if  any 

Facility  type  offset  within  its  mode  of 
transport 
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Directory  Type :  Scenario 


FLEET 

Administrative  Fleet 

#  K?  Field  Name 
_ I - 

1  Y  Fleet 

2  Planning  Fleet 

3  Vehicle  Capacity 


Edit  Limits  Identifies  groups  of  vehicles  with  common  administrative  characteristics  for  vehicle 
availability. 


Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 


A15 

PLANFLT 

0,100 


LATECLAS 
Lateness  Class 

#  K?  Field  Name 

1 _ 1 _ 

1  Y  Lateness  Class 


2  Days  Late 


Ais  Fleet  name 

planflt  PLANFLT  Yes  Planning  fleet  to  which  this  fleet  belongs 

Percent  fleetvehcappc  0,100  Yes  %  Percent  of  each  lift  vehicle  which  is 

available,  applied  uniformly  across  all 
vehicles  in  the  Fleet 

R^ii-  T.mitq  I  ngfingfi  lateness  classifications  for  the  RPTLATE  lateness  summary  report  (e.g.  On  Time, 
Within  1  Day  Late,  Total  Scheduled,  Total  Unscheduled,  etc.)  _ 


Model  Datatype 


lateclasdays 


Domain | Lookup  B|V  Unit  Meas  Description 


Lateness  Clas 


Day sDe 1 ayToHr  Yes  day 


Lateness  classification  for  reporting 
lateness  summaries  (e.g.,  Ontime, 
Scheduled,  Unscheduled,  Within  1  Day  Late, 
etc.) 

Maximum  days  late  allowed  for  inclusion  in 
this  lateness  classification 


Edit  Limits  I  Defines  the  capacity  for  constrained  links  and  units  of  measure 


|  Node  Link  Capacity 


#  K?  Field  Name 
I _ 1 - 

1  Y  From  Node 

2  Y  To  Node 

3  Y  Transport  Mode 

4  Y  Link  Capacity  Measure 

5  Link  Capacity  Limit 


Model  Datatype 


1 inkcap_measure 
node 1 ink_capacity 


Domain | Lookup  B|V  Unit  Meas  Description 


NODELINK 

NODELINK 

NODELINK 

MEASURE 

Long>=0 


firstlinkcap_event  LNKEVENT 


From  node  for  this  link  with  link  capacity 
To  node  for  this  link  with  link  capacity 
Transport  mode  for  this  link  with  link 
capacity 

Unit  of  measure  for  this  link  capacity 
Limit  on  cargo  throughput  capacity  for  this 
link 

First  event  for  this  capacitated  link 


LOADRATE 
Load  Rate 


#  K?  Field  Name 


Edit  Limits 
Keys  Comput 


Specifies  transfer  rates  for  loading  and  unloading 


Model  Datatype 


Domain | Lookup  B|v  Unit  Meas  Description 


1  Y  Vehicle  Type 

2  Y  Facility  Type 

3  Y  Cargo  Type 

4  Hourly  Load  Rate 


Hourly  Unload  Rate 


VFACTYPE 
VFACTYPE 
CARGTYPE 
Short >=0 


MAJUNIT 
Major  Unit 


#  K?  Field  Name 

i  < 


1  Y  Major  Unit 

2  Requirement  Type 

3  Major  Unit  MOE 


VFACTYPE  Vehicle  type 

VFACTYPE  Facility  type  at  the  node 

ldratecrgtyp  CARGTYPE  Cargo  type  for  the  transport  mode 

ldrate  Short>=0  Q/hr  Hourly  load  rate  to  load  this  cargo 

category  grouping  on  this  vehicle  type  at 
this  berth  type  expressed  in  the  cargo 
basic  quantity  units  (loading  can  occur 
only  during  the  facility  open  hours) 

te  uldrate  Short >=0  Q/hr  Hourly  unload  rate  to  unload  this  cargo 

category  grouping  on  this  vehicle  type  at 
this  berth  type  expressed  in  the  cargo 
basic  quantity  units  (unloading  can  occur 
only  during  facility  open  hours) 

Scaling  thruputscale  Byte>=0  Yes  %  Cargo  throughput  scaling  which  adjusts  the 

cargo's  required  facility  and  node 
throughput  capacity  (100%  represents 
standard  throughput  scaling,  0%  means  the 
cargo  does  not  affect  throughput  capacity 
at  all,  50%  means  the  cargo  consumes  half 
throughput) 

Edit  Limits  Lists  each  major  unit,  which  in  GDAS  is  a  grouping  of  requirements,  either  unit  or  non¬ 
unit,  used  to  display  delivery  profiles  and  compute  overall  closure  times  for  related 


6  Cargo  Throughput  Scaling  thruputscale 


Byte>=0  Yes  % 


Model  Datatype 


majunitreqtyp 

majunitmoe 


Domain | Lookup  B|V  Unit  Meas  Description 


4  Computed  Closure  Day  maj unit close 


5  Closure  Required  Cargo  %  majunitcrgclose 


6  Closure  Required  PAX  %  majunitpaxclose 


7  Major  Unit  Description 


REQTYPE 

0,150 


DayToHr 


Major  unit  name  for  analysis  of  requirement 
closures  and  measures  of  effectiveness 
Requirement  type  for  this  major  unit 
Measure  of  effectiveness  (MOE)  rating  for 
this  major  unit  (e.g.,  brigade  count  or 
combat  power)  as  defined  by  the  analyst  to 
compute  cumulative  MOE  delivery 

day  (hr)  Closure  day  for  the  major  unit  based  on 
both  the  Pax  and  cargo  closure  minimum  % 
specified  in  the  MajUnit  table 

%  Minimum  percent  of  the  cargo  which  must  be 

delivered  in  order  to  calculate  unit 
closure  (if  the  %  is  never  attained, 
closure  is  based  on  the  last  portion 
delivered) 

%  Minimum  percent  of  the  passengers  which 

must  be  delivered  in  order  to  calculate 
unit  closure  (if  the  %  is  never  attained, 
closure  is  based  on  the  last  portion 
delivered) 

Major  unit  description 
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Directory  Type :  Scenario 


MAPLAYER 


Edit  Limits  Sets  mapping  layer  characteristics  such  as  color  and  symbol  which  can  be  edited  by  the 
user 


1 - 

#  K? 

Field  Name 

_ i - 

Model  Datatype 

Domain  |  Lookup  B|  Uni 

1  Y 

Layer  ID 

Table  Any  Cas 

2 

Layer  Label 

Menu  Item 

Yes 

3 

Map  Table 

MAPTABLE 

Yes 

4 

Layer  Value 

A255 

1  Ye 

5 

Begin  Off 

A3 

6 

Symbol  Type 

A25MAPSHAPE 

7 

Symbol  Color 

MAP COLOR 

8 

Symbol  Size 

0,48 

9 

Symbol  Min  Scale 

Short >«0 

mi 

10 

Symbol  Max  Scale 

Short >=0 

mi 

11 

Label  Font 

MAPFONT 

12 

Label  Style 

MAPFSTYL 

13 

Label  Color 

MAPCOLOR 

14 

Label  Size 

Short >=0 

mi 

15 

Label  Min  Scale 

Short >=0 

16 

Label  Max  Scale 

Short >=0 

mi 

Description 


The  unique  layer  ID  (generated  as  a  table 
in  the  mapping  application) 

Layer  description  used  in  the  mapping 
application  menus 

Lookup  into  the  MapTable  table  for  the 
original  table 

The  Layer  Field  value  for  this  layer  (may 
be  blank  only  if  the  table  is  all  on  one 
layer) 

Yes  if  the  layer  display  should  be  off 
initially 

The  mapping  symbol  shape  or  line  type 
The  color  of  the  symbol 

The  point  size  of  the  node  symbol  or  line 
width 

The  minimum  scale  (closest  in)  for  which 
this  layer  is  displayed,  express  as  width 
of  view  in  miles 

The  maximum  scale  (farthest  out)  for  which 
this  layer  is  displayed,  expressed  as  width 
of  view  in  miles 

The  font  type  for  the  layers  labels 
The  font  style  for  the  layer  labels 
The  font  color  for  the  layer  labels 
The  font  point  size  for  the  layer  labels 
The  minimum  scale  for  which  the  label  is 
displayed,  expressed  as  width  of  image  in 
miles 

The  maximun  scale  for  which  the  label  is 
displayed,  expressed  as  width  of  image  in 
miles 


MAPLINK 

Map  Link 

Edit  Limits 

Lists  route 

links  extracted  from  NODELINK  for  the  world  map  display 

#  K?  Field  Name 

Model  Datatype 

( Domain | Lookup ( B | V ^ Unit  Meas 

j Description 

1  Y  From  Node 

2  Y  To  Node 

3  Y  Transport  Mode 

4  Is  Link  Disabled? 

NODELINK  i 

NODELINK 

NODELINK 

Yesflag 

From  node  extracted  from  NodeLink  for  the 
world  map  display 

To  node  extracted  from  NodeLink  for  the 
world  map  display 

Transport  mode  for  this  link  (only  one  link 
is  permitted  for  each  mode;  multiple  links 
can  be  created  by  adding  nodes) 

Yes  if  the  link  is  available,  blank 
otherwise 

MAPNODE 

Map  Node 

Edit  Limits 

Lists  nodes 

and  locations  extracted  from  NODE  for  the  world  map  display 

#  K?  Field  Name 

Model  Datatype 

i 

Domain  |  Lookup  ( B  |  V  ^  Unit  Meas 

^  Description 

1  Y  Node  Name 

2  Node  Type 

3  Node  Latitude 

4  Node  Longitude 

5  Is  Node  Disabled? 

NODE 

NODETYPE 

Lat  Yes  deg  min  H 

Lon  Yes  deg  min  H 

Yesflag 

Node  name  or  location  extracted  from  NODE 
for  the  world  map  display 

Node  type  for  world  map  graphics  display 
Node  latitude  in  dd  mm  H 

Node  longitude  in  ddd  mm  H 

Yes  if  the  node  is  disabled,  otherwise 
blank 

MAPREQ 

Map  Req  Channels 

Edit  Limits 
Output 

Summarizes  requirement  quantities  by  origin/destination  channel  for  mapping 

#  K?  Field  Name 

^ Model  Datatype 

( Domain | Lookup ( B | V  ^  Unit  Meas 

Description 

1  Y  Origin 

2  Y  Destination 

3  Y  Cargo  Measure 

4  Total  Quantity 

NODE 

NODE 

BASMEAS 

Double >=0  Q 

Origin  of  this  flow  channel 

Destination  of  this  flow  channel 

Basic  cargo  quantity  measure 

Total  quantity  for  this  flow  channel  and 
basic  measure 

MAPTABLE 

Mapping  Table  Specs 

Edit  Limits 
Hide 

Defines  the 

map  table  specifications 

#  K?  Field  Name 

i  t 

( Model  Datatype 

Domain | Lookup  B|VfUnit  Meas 

Description 

1  Y  Map  Table 

2  Map  Type 

3  Number  Keys 

4  Parent  Table 

5  Browse  Table 

TABLE 

MaptyPE  Yes 

1,7 

MAPTABLE 

TABLE 

The  name  of  a  mapping  source  table 

The  type  of  mapping  display  for  this  table 
(Node  or  Link) 

The  number  of  keys  is  the  source  node  table 
The  node  source  table  for  link  mapping 
tables 

A  table  with  additional  browse  information 
about  the  records  in  the  map  table  (this 
table  have  initial  keys  matching  Map  Table) 
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Directory  Type :  Scenario 


MAPTABLE  Edit  Limits 

Mapping  Table  Specs  Hide 


Defines  the  map  table  specifications 


#  K?  Field  Name 

_ j _ 

6  Browse  File 


7  Chart  Table 


8  Layer  Field 


9  Latitude  Field 

10  Longitude  Field 

11  Picture  Field 

12  Label  Field 

13  Is  Disabled  Field 

14  Remove  Reverse  Links 

15  Subset  Table 


Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 


Yesf lag 


16  Subset  Field 


MAPTHRUP 

Map  Node  Thruput 

#  K?  Field  Name 
I _ l - 

1  Y  Node 

2  Y  Measure 

3  Y  Day 

4  Quantity 


MAPVEH 
Map  Vehicle 

#  K?  Field  Name 


1  Y  Vehicle  Number 


Vehicle  Type 
Vehicle  Identifier 
Vehicle  Fleet 
Mode 

Latitude  Computed 
Longitude  Computed 


A  report  file  with  additional  browse 
information  about  the  records  {this  report 
must  have  searchable  text  with  matching  key 
field  values,  with  multiple  key  field 
strings  separated  by  commas) 

A  table  with  charting  information,  first 
keys  must  match  the  mapping  table,  followed 
by  an  optional  key  field  for  crosstab 
headings  (such  as  Product) ,  followed  by  a 
key  field  such  as  Date  for  the  x  axis, 
followed  by  a  chart  value 
The  layer  selection  field  for  the  mapping 
table  {blank  if  the  entire  table  is  plotted 
on  one  layer) 

The  latitude  field  for  a  node  table 
The  longitude  field  for  a  node  table 
The  picture  name  field  for  a  node  table 
The  label  field  for  the  mapping  table 
Field  which  determins  if  this  object  is 
disabled 

Yes  for  a  map  link  table  for  which  reverse 
links  are  to  be  removed,  otherwise  blank 
The  table  to  be  used  for  subset  values, 
with  the  first  keys  matching  the  Map  Table, 
and  an  additional  key  representing  disjoint 
subsets  (e.g.  location  date) 

The  dynamic  subsetting  field  for  the 
mapping  table 


Edit  Limits  Summarizes  node  daily  throughput  quantities  for  map  chart  display 
Output  _ _ 


Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 


NODE 

MEASURE 

simendday 

Double>=0 


Node  for  map  throughput  chart 

Cargo  quantity  measure  for  throughput  chart 

Day  for  map  throughput  chart 

Total  throughput  quantity  for  this  node, 

day,  and  quantity  measure 


Edit  Limits  Lists  vehicles  extracted  from  VEHICLE  for  the  world  map  display 
Output  _ 


Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 


VEHICLE 

VEHFLEET 

VEHFLEET 

VEHFLEET 

MODE 

Lat 


Vehicle  unique  sequential  number  extracted 

from  the  VEHICLE  table  for  the  map  display 

Vehicle  type 

Vehicle  identifier 

Vehicle  fleet  for  this  vehicle 

Transport  mode  for  this  vehicle 

deg  min  H  Current  latitude  computed  for  the  current 
date  and  time 

deg  min  H  Current  longitude  computed  for  the  current 
date  and  time 


MEASURE 

Measure 

#  K?  Field  Name 

I - 1 - 

1  Y  Measure  Type 


Edit  Limits  Lists  the  types  of  dimensional  measures  used  to  define  cargo,  vehicle  compartments,  or 
node  facilities 


Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 


2  Measure  Class  mease las 

3  Matching  Cargo  Measure  measergmeas 


4  Unit  of  Measure 

5 


basiemeas 

measrptmeas 


MEASCLAS 

MEASURE 


A25 

BASMEAS 


Type  of  measure  used  for  describing  cargo, 
vehicle  compartments,  or  node  facilities 
(e.g.,  Ston,  Mton,  Sq  Ft,  CBbl,  Max  Ft., 
Max  Item  Ston,  etc.) 

Measure  class  for  this  measure  type 
Matching  cargo  measure  which  is  used  for 
calculating  constraints  using  this 
constraint  measure 

Unit  of  measure  for  this  type  of  measure 
Basic  measure  corresponding  to  this 
measure,  if  any 
The  matching  record  in  RPTMEAS 
corresponding  to  this  measure,  if  any 


MISSION 

Mission 


#  K?  Field  Name 

■  i 


1  Y  Special  Mission 


2  Mission  Begin  Day 


Edit  Limits  Lists  special  missions  such  as  TACS,  AFOE,  etc. 


Model  Datatype 


missbeg 


Domain  I  Lookup  B|V  Unit  Meas  Description 


DayToHr 


Name  of  a  special  mission,  e.g.  Marine 
amphibious  task  force,  or  crane  ship,  or 
other  mission 

day  (hr)  Begin  day  that  a  designated  special  mission 
ship  or  fleet  is  restricted  to  matching 
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Directory  Type :  Scenario 


MISSION 

Mission 


#  K?  Field  Name 


3  Mission  End  Day 


Edit  Limits  Lists  special  missions  such  as  TAGS,  AFOE,  etc. 


Model  Datatype  Domain | Lookup  B|V  Unit  Meas  Description 


4  Delay  Hours  After  Offload  missdelay 


special -mission  requirements  only 

DavToHr  day  (hr)  End  day  that  a  designated  special  mission 

y  ship  or  fleet  is  restricted  to  matching 

special-mission  requirements  only 

Hour sDe lay  hr  Additional  delay  hours  in  the  depart  time 

after  offload  of  special  mission  cargo  at 
its  ultimate  destination  node  (delays  the 
vehicle  at  the  stop,  not  the  cargo 
delivery) 


MODE 

Edit  Limits 

Mode  of  Transport 

Lists  transportation  modes  {air,  sea,  motor,  organic,  rail,  intratheater  air,  etc.) 


#  K?  Field  Name 

I _ ! - 

1  Y  Transport  Mode 


Model  Datatype 


Domain| Lookup  b|V  Unit  Meas  Description 


2  Scheduling  Model  Type  schedtype 

3  ASCII  Code  Abbreviation  modechar 


list exmode 

listvehtype 

maxrange 


SCHEDTYP  Yes 


ASCII  Upper 


EXCLUDE 
VEHTYPE 
Short >=0 


hasmission 
listmodef leet 


Name  of  a  transport  mode  (e.g.  Airlift, 
Sealift,  Rail,  Motor,  Pipeline,  Generic, 
etc. ) 

Scheduling  model  algorithm  type  used  for 
this  mode  of  transport 

ASCII  code  of  a  single  upper  case  letter 
abbrieviation  used  by  the  model  to  display 
on-screen  activity  progress  (S  for  Sea,  A 
for  Air,  etc.,  with  lower  case  for  planning 
and  upper  case  for  scheduling  and 
simulation) 

List  of  exclusions  for  this  mode,  if  any 

List  of  vehicle  types  for  this  mode 

Max  empty  range  and  max  link  distance  over 

all  vehicles  of  this  mode 

Flag  that  is  set  to  TRUE  if  a  mode  can 

convoy,  FALSE  otherwise 

Flag  that  is  set  to  TRUE  for  the  current 
mode  if  the  requirement  has  a  mission 
List  of  planning  fleets  for  this  mode 


Edit  Limits  Lists  nodes  and  locations  for  all  ports,  origins,  destinations,  transhipment  points,  and 
routing  points  _ _ 


#  K?  Field  Name 


1  Y  Node  Name 


Node  Type 
Node  Latitude 
Node  Longitude 
Geoloc  Code 
Theater 

Attrit  Probability  %% 
Is  Node  Disabled? 


Model  Datatype 


nodelat 
node Ion 
nodegeoloc 
nodethtr 
nodeattr 

isnodegone 


Domain | Lookup  B|V  Unit  Meas  Description 


Ai5  Node  name  corresponding  to  a  port, 

transhipment  point,  origin,  destination, 
routing  point  etc. 

NODETYPE  Node  type  for  world  map  graphics  display 

Lat  Yes  deg  min  H  Node  latitude  in  dd  mm  H 

Lon  Yes  deg  min  H  Node  longitude  in  ddd  mm  H 

A4  Node  geoloc  code,  if  any 

THEATER  Yes  Theater  that  the  node  is  located  in,  if  any 

0, 9999  %%  Discrete  probability  of  attrition  or 

breakdown  when  departing  this  node 
Yesflag  Yes  if  the  node  is  disabled,  otherwise 

blank 


9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 


f irstlink 
f irstfac 
firstnodecap 

NODELINK 

FACILITY 

NODECAP 

listexnode 

nodehrptr 

EXCLUDE 

NODCAPHR 

nodehpd 

0,24 

nodestoroffset 

MEASURE 

nodethrupoffset 

MEASURE 

f irstconvoy 

CONVOY 

prednode 

NODE 

label 

Long>=0 

join_label 

Boolean 

Node  first  link 
Node  first  facility 

First  node  throughput  in  the  NODETHRU 
table,  if  any 

List  of  exclusions  for  this  node,  if  any 
First  record  in  the  NODCAPHR  table,  if  any, 
for  this  node  on  the  current  simulation  day 
Node  operating  hours  per  day  based  on  the 
maximum  facility  hours  at  the  node 
Offset  for  the  first  NODECAP  record  for 
storage  relative  to  the  first  record 
Offset  for  the  first  NODECAP  record  for 
throughput  relative  to  the  first  record 
Node  first  convoy  record  (currently  not 
input  in  Preprocessor  because  of  file 
limits) 

Predecessor  node  in  the  shortest  spanning 
tree  algorithm  in  NetTool 
Distance  from  the  root  in  the  NetTool 
shortest  spanning  tree  algorithm 
Temporary  flag  for  finding  the  common  root 
of  two  nodes  in  the  NetTool  spanning  tree 


21 

22 

23 

24 

25 


listlink  NODELINK 

listnodevent  NODEVENT 

listcargo  CARGO 

nextnode  NODE 

prednodevent  NODEVENT 


algorithm 

List  of  links  at  the  node  in  NetTool 
Pointer  to  list  of  nodevent  records  for 
this  node 

List  pointer  for  the  multicriteria  list  of 
cargos,  paralleling  mheapcargo 
Next  pointer  for  the  list  of  nodes 
Pointer  to  the  last  begin  pred  nodevent 
record  accessed  by  the  subtract  capacity 
function 
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Directory  Type :  Scenario 


NODE 

Node 

Edit 

Limits 

Lists  nodes  and 
routing  points 

locations 

for  all  ports,  origins,  destinations,  transhipment  points,  and 

#  K?  Field  Name 

Mod* 

si  Datatype 

Domain  |  Lookup  ^  B  |  V  ^  Unit  Meas 

Description 

J - — - * 

26 

f irstconsrate 

CONSRATE 

First  supply  consumption  rate  for  this  node 

N0DE2 

Shadow  Node 

Edit  Limits 
Display  Onl 

Provids  a  shadow  copy  of 

the  NODE  table  for 

form  and  report  linkages 

#  K?  Field  Name 

Mode 

i 

si  Datatype 

f Domain | Lookup ( B | V ^ Unit  Meas 

(Description 

i - 1 - - — 

1  Y  Node  Name 

2  Node  Type 

3  Node  Latitude 

4  Node  Longitude 

5  Geoloc  Code 

6  Theater 

7  Attrit  Probability  %% 

8  Is  Node  Disabled? 

NODE 

NODETYPE 

Lat 

Lon 

A4 

THEATER 

0,9999 

Yesflag 

Yes  deg  min  H 
Yes  deg  min  H 

Yes 

%% 

Node  name  corresponding  to  a  port, 
transhipment  point,  origin,  destination, 
routing  point  etc. 

Node  type  for  world  map  graphics  display 
Node  latitude  in  dd  mm  H 

Node  longitude  in  ddd  mm  H 

Node  geoloc  code,  if  any 

Theater  that  the  node  is  located  in,  if  any 
Discrete  probability  of  attrition  or 
breakdown  when  departing  this  node 

Yes  if  the  node  is  disabled,  otherwise 
blank 

NODECAP 

Node  Capacity 

Edit 

Limits 

Defines  total  throughput 

at  each  node  for  all  facilities  at  the  node 

(#  K?( Field  Name 

( Model  Datatype 

Domain | Lookup  B|V^Unit  Meas 

Description 

1  Y  Node  Name  thrupnode 

2  Y  Node  Capacity  Measure  nodemeas 

3  Total  Node  Capacity  nodecap 


NODE 

MEASURE 

nodecap 


Node  having  throughput  or  storage  limits 
Unit  of  measure  for  overall  cargo  handling 
capacity  at  the  node 

Q  or  Q/hr  Hourly  throughput  rate  or  total  storage 

cargo  handling  capacity  at  the  node  for  all 
facilities  combined 


4 

5 

nodecaps tor 

nodecapsathrs 

node cap  Q 

HoursDelay  hr 

Remaining  storage  capacity  if  the  measure 
is  storage 

Start  hour  on  the  current  day  for  which 
this  facility  storage  capacity  measure 
became  saturated  (0  if  unsaturated) 

NODELINK 

Node  Link 

Edit  Limits 

Lists  single 

leg  links  between  nodes  for 

transportation 

#  K?  Field  Name 

1 _ l - 

^Model  Datatype 

Domain | Lookup  BlV^Unit  Meas  ■Description 

1  Y  From  Node 

2  Y  To  Node 

3  Y  Transport  Mode 

linktonode 

linkmode 

NODE 

NODE 

MODE 

4  Is  Link  Disabled? 

islinkgone 

Yesflag 

5  Link  Dist 

linkdist 

Short >=0 

nmi 

6  Added  Delay  Hours 

7  Speed  Change 

linkdelay 

linkspeedincr 

HoursDelay 

-99,999 

hr 

nmi /hr 

8  Speed  Limit 

linkspeedlim 

1,999 

nmi /hr 

9  Link  Rating 

linkrating 

0,9999 

10  Attrit  Daily  Rate  %% 

linkattr 

0,9999 

%%/day 

11 

is_barrier 

Boolean 

12 

13 

next link 
track_count 

NODELINK 

Short >=0 

14 

15 

f irstlinkcap 
listlnkevent 

LINKCAP 

LNKEVENT 

Prom  node  name 
To  node  name 

Transport  mode  for  this  link  (only  one  link 
is  permitted  for  each  mode;  multiple  links 
can  be  created  by  adding  nodes) 

Yes  if  the  link  is  disabled  and 
unavailable,  blank  otherwise 
Link  distance  in  nautical  miles,  computed 
by  the  model  based  on  great  circle  if  0,  or 
can  also  be  set  by  the  user  (but  will  be 
recalculated  as  the  great  circle  distance 
if  less  than  the  great  circle  distance) 
Delay  time  on  this  link  in  hours 
Speed  change  (positive  for  increase, 
negative  for  decrease)  which  is  added  to 
the  transport  speed  on  this  link  (for 
sealift  an  approximate  calculation  is  to 
get  an  equivalent  distance  change) ,  in 
nautical  mph 

Speed  limit  which  constrains  the  allowable 
transport  speed  on  this  link  (for  sealift 
an  approximated  distance  change  is 
computed) ,  in  nautical  mph 
User-definable  link  rating  which  limits  the 
size  of  vehicles  that  are  permitted  through 
this  link,  based  on  their  Route  Type;  for 
example ,  the  Link  Rating  may  represent 
maximum  canal  draft,  excluding  deep  draft 
ships 

Attrition  or  breakdown  rate  on  this  link 
for  exposure-based  attrition 
Boolean  flag  set  to  one  if  a  link  is  an 
obstacle  rather  them  a  transport  path,  zero 
otherwise 

Next  link  at  the  same  node  in  NetTool 
Count  of  the  number  of  times  a  link  has 
appeared  in  a  route 

First  pointer  to  a  link  capacity  record 
List  pointer  to  list  of  events  for  this 
link,  if  any 
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Directory  Type:  Scenario 


NODETYPE 

Shape 


Edit  Limits  Lists  the  node  types  for  world  map  display 


#  K?  Field  Name 


Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 


1  Y  Node  Type 


A15 


Node  type  for  world  map  display 


PARAM 
Parameter 


Edit  Limits 
Modify 


Sets  parameters  for  the  scheduling  model 


#  K? 

Field  Name 

i  i 

Model  Datatype 

Domain | Lookup  ^ 

1  Y 

2 

3 

Scenario  Name 

Scenario  Description 
Vehicle  Snapshot  Day 

currday 

A8 

A50 

simendday 

4 

Vehicle  Snapshot  Hour 

currhr 

Hour 

5 

6 

7 

Security  Classification 
Last  Simulation  Day 

Do  Dynamic  Resupply? 

simendday 

dodynres 

CLASSIF 

simendday 

Yesflag 

8 

Do  Static  Resupply? 

dostatres 

Yes flag 

9 

Static  Order  Interval 

order_interval 

1,99 

10 

Do  Convoying? 

docnvy 

Yesflag 

11 

Do  Convoy  At  Intervals? 

docnvyinterval 

Yesflag 

12 

13 

Convoy  Begin  Day 

Max  Speed  Convoyed 

cnvybeg 

cnvymaxspeed 

DayToHr 

1,99 

14 

Max  Convoy  Diversion 

cnvymaxdivert 

Short >=0 

15 

Do  Attrition? 

doattrit 

Yesflag 

16 

Do  Parameter  Vary? 

doparam 

Yesflag 

17 

Number  of  Stochastic  Runs 

nstatruns 

0,99 

18 

Personnel  Lead  Days 

prsnleadtim 

DaysDelayToHr 

19 

Random  Number  Seed 

seed 

Short >=0 

20 

Minimum  Vehicle  Load  % 

vehminpc 

% 

21 

Minimum  Cargo  Load  % 

crgminpc 

% 

22 

Do  Balanced  Forces? 

balance_forces 

Yesflag 

23 

totncrg 

Long>=0 

24 

nrofcpt 

CPTTYPE 

25 

curday 

0,999 

26 

tvstartrec 

TIMEVARY 

27 

maxnomspeed 

Long>=0 

28 

mintonmipen 

Long>=0 

29 

simend 

DayToHr 

30 

cnvyminspeed 

Short >=0 

31 

listcrgonboard 

CARGO 

32 

listcrgreject 

CARGO 

33 

34 

curdayf irsthr 
tottons 

DayToHr 

Long>=0 

Unit  Meas  Description 


day 

hour 

Yes  day 


day  (hr) 


Yes 


day  (hr) 
nmi/hr 


Yes  nmi 


day  (hr) 


Scenario  short  name  and  directory  name 
Scenario  description 

Current  day  used  to  interpolate  vehicle 
locations  for  the  world  map  display 
Current  hour  used  to  interpolate  vehicle 
locations  for  the  world  map  display 
Security  classification  level  of  the  data 
Last  day  to  simulate 

Yes  if  dynamic  resupply  generation  is  to  be 
performed  in  the  model 
Yes  if  static  resupply  requirement 
generation  is  to  be  performed  (can  be  left 
blank  to  re-use  the  dynamic  resupply 
computed  from  a  prior  run) 

Aggregation  interval  for  computing  resupply 
order  quantities 

Yes  if  convoying  is  to  be  performed  using 
the  CONVOY  table,  blank  otherwise 
Yes  if  convoys  are  to  be  scheduled  at 
regular  intervals  independent  of  convoy 
size  (convoys  can  then  be  scheduled  more 
efficiently) 

Day  that  convoy  operations  begin 
Max  speed  limit  above  which  ships  are  not 
convoyed  and  instead  travel  independently, 
in  nautical  mph 

Max  diversion  distance  above  which  ships 

are  not  convoyed  and  instead  travel 

independently,  in  nautical  miles 

Yes  if  attrition  or  breakdown  is  to  be 

performed,  blank  otherwise 

Yes  if  parametric  variations  are  to  be 

performed,  blank  otherwise 

Number  of  runs  if  stochastic  simulation  is 

performed  using  probability  distributions 

Earliest  lead  time  that  personnel  can 

arrive  prior  to  other  cargo  in  the  same 

requirement 

Random  number  seed  for  stochastic 
simulations  including  attrition 
Minimum  percent  of  the  total  vehicle 
compartment  capacity  which  must  be  filled 
to  be  worth  assigning  a  cargo,  unless  the 
Minimum  Cargo  Load  %  below  is  satisfied 
Minimum  percent  of  a  cargo  which  must  be 
loadable  to  be  worth  assigning  a  cargo  to  a 
vehicle,  unless  the  Minimum  Vehicle  Load  % 
above  is  satisfied 

Flag  to  dynamicaly  replace  reqtype  priority 
with  percent  delivered 

Total  number  of  cargos  to  be  planned,  used 
in  displaying  progress  on  screen 
Number  of  compartments  for  the  current 
vehicle  type  with  capacities  stored  in 
VCPTMEAS 

Current  day  in  the  simulation  model  (not 
converted  to  hours) 

Current  starting  record  in  the  TIMEVARY 
table  for  updating  the  next  set  of  time 
variations 

Max  planning  mode  speed  for  calculating 
lower  bounds,  in  nautical  mph 
Max  ton-mile  penalty  scaled  by  1000  (in 
mils /ton/mi)  used  for  mode  planning  lower 
bounds  (equals  min  of  1000*nompen/nomspeed 
over  all  modes) 

Simulation  ending  hour  for  the  model, 
including  an  extra  shutdown  day 
Required  minimum  speed  for  ships  to  convoy 
(computed  as  the  max  convoy  speed) ,  in 
nautical  mph 

List  of  cargos  onboard  the  current  trip  in 
expected  value  attrition  calculations 
List  of  rejected  cargos  which  could  not  be 
scheduled 

First  hour  of  the  current  simulation  day 
Total  requirement  tonnage  used  for  the 
onscreen  display  of  progress  (including 


day 

nmi/hr 

mils/ton/n 

hr 

nmi/hr 


day  (hr) 
ston 
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Directory  Type :  Scenario 


PARAM 

Parameter 

Edit  Limits 
Modify 

Sets  parameters 

for  the  scheduling  model 

f  K? ( Field  Name 

Mod* 

_ 1 _ 

;1  Datatype 

Domain  |  Lookup  ^(V  Unit  Meas  description 

_ _ _ 

35 

tot intransit 

Long>=*0 

ston 

36 

totde liver ed 

Long>=0 

ston 

37 

listcrgflow 

CARGO 

38 

listnode 

NODE 

39 

listgreedyveh 

CARGO 

40 

last_resupply_order 

Long>=0 

Total  intransit  tonnage  used  for  the 
onscreen  display  of  progress  (including 
other  basic  measures  converted  to  stons) 
Total  delivered  tonnage  used  for  the 
onscreen  display  of  progress  (including 
other  basic  measures  converted  to  stons) 
List  of  vehicle  flow  cargo's  which  have 
been  partially  scheduled 
List  of  nodes  with  cargos  ready  for 
scheduling,  sorted  by  the  earliest 
scheduling  priority  of  cargos  at  each  node 
List  of  cargos  suitable  for  loading  on  a 
greedy  vehicle 

Last  resupply  order  number  saved  for 
snapshot  restarts 


PLANFLT 

Edit  Limits 

Planning  Fleet 

Lists  the  fleet  aggregations  used  for  planning  modes, 
pre-scheduled  routes 


ports,  cargo  configurations,  and 


#  K?  Field  Name 
I _ l - 


Model  Datatype 


^ Domain  1  Lookup [V^Unit  Meas 


Description 


1  Y  Planning  Fleet 

2  Fleet  Mode  fleetmode 

3  Transport  Agent 

4  Planning  Speed  nomspeed 


5  Planning  Delay  Hours  nomdelay 

6  Planning  Ton -Hour  Penalty  nompen 

7  Plan  Fleet  Productivity  % 


A15 


MODE 

A15 

1,999 


Yes 

Yes 

Yes  nmi/hr 


Hour sDe lay  hr 


B  Utilization  Rate  % 


vuterate 


maxwaittime 


1,999  Yes  $ /hr/ ton 

Float  0,100  %  of  C-mi/ 

1,100  % 


9  Greedy  Vehicle  Wait 

10  Standard  Depart  Interval 

11  Stop  Arrival  Tolerance  route^tolerance 

12  Route  Delay  Penalty  rout e_de lay ^penalty 


13  Remain  On  Route? 

14  Description 

15 

16 

17 

18 

19 

20 
21 


r ema in_on_rout e 

nextmodef  leet 
f irstplnf ltcp 

listflevent 

listexfleet 

skipjplanflt 

hasjvehicle 

predfl event 

origin_depart_time 


HoursDelay 
Short >=1 
DaysDelayToHr 
Short >=0 

Yesflag 

A50 

PLANFLT 

PLNFLTCP 

PFLEVENT 

EXCLUDE 

Boolean 

Boolean 

PFLEVENT 

DayToHr 


hr 

day 

day 


Aggregation  of  fleets  used  for  planning 
modes,  ports,  cargo  configurations,  and 
prescheduled  routes 

Transport  mode  used  by  the  planning  fleet 
Transportation  agent  or  company  identifier 
for  this  fleet 

Nominal  planning  speed  in  nautical  tnph  or 
knots  for  planning  routes  and  target  lift 
dates  (this  is  a  planning  speed,  not  a 
scheduling  or  simulation  speed,  and  should 
be  set  to  match  slower  vehicles) 

Nominal  planning  delay  time  in  hours  for 
each  mode  change  to  allow  for  vehicle 
repositioning,  loading,  unloading,  and 
other  delays  for  planning  routes  and  target 
lift  dates  (accounts  for  repositioning  in 
planning,  not  just  load  times) 

Nominal  penalty  per  ton  per  hr  for 
transport  via  this  vehicle  type  for 
planning  routes  and  target  lift  dates 
Plan  fleet  useful  planning  percent 
allocation  or  productivity  %,  expressed  as 
a  percent  of  transport  lift  flow  capacity 
(Mton-mi/day,  SqFt-mi/day,  etc.)  as 
contributed  by  the  first  measure  of  each 
compartment 

Vehicle  effective  utilization  (UTE)  rate 
expressed  as  a  percent  usage  per  day  based 
on  maintainability,  logistics  support,  re¬ 
basing,  non-productive  use  (applies  to 
travel  time  only,  not  time  in  port,  and 
cause  recovery  delays  after  trips) 

Max  wait  time  for  evaluating  additional 
cargo  at  the  same  POE  after  an  assignment, 
used  in  the  vehicle  scheduling  algorithm 
Standard  depart  time  interval  for  a 
prescheduled  route,  stored  for  reference 
only  and  not  used  to  generate  routes 
Time  window  tolerance  for  early  or  late 
arrival  at  the  prescheduled  stops  on  this 
route 

Penalty  for  the  delay  of  prescheduled  stops 
when  inserting  new  stops,  the  input  value 
is  the  penalty  of  one  day  delay  in  cents, 
with  increasing  cost  for  greater  delays 
Yes  if  the  prescheduled  ship  should  stay  on 
its  prescheduled  route  only  up  through  the 
Route  Last  Day 

Description  of  the  prescheduled  route 
Next  fleet  in  list  of  fleets  for  a  mode 
First  matching  record  in  the  table  of 
capacities  for  this  planning  fleet 
List  of  capacity  usage  events  for  this 
fleet 

List  of  exclusions  for  this  planning  fleet, 
if  any 

Planing  fleet  flag  to  skip  evaluation  used 
in  mode  planning 

Flag  that  is  true  if  the  planning  fleet  has 
vehicles 

Pointer  into  the  list  of  events  to  make 

list  scans  take  less  time 

Estimated  latest  time  that  a  vehicle  from 
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Directory  Type :  Scenario 


PLANFLT 
Planning  Fleet 

#  K?  Field  Name 


Edit  Limits  Lists  the  fleet  aggregations  used  for  planning  modes,  ports,  cargo  configurations,  and 
pre- scheduled  routes  _ _ 


Model  Datatype 


planflt_start 


Domain | Lookup  B|V  Unit  Meas  Description 


DayToHr 


the  current  planning  fleet  can  leave  the 
origin  last_hour  when  its  mode  isn’t 
adjacent  to  the  origin 

The  minimum  start  schedule  time  for  all 
vehfleets  for  this  planflt  record 


PLNFLTCP  Edit  Limits  Stores  the  allocated  throughput  capacity  for  each  planning  fleet  for  use  in  mode  and 

Plan  Fleet  Capacity  Output  port  selection,  as  calculated  from  the  percent  allocation  in  PlanFlt _ 

1  Datatvoe  Domain | Lookup  B|V  Unit  Meas  Description 


#  K?  Field  Name 


1  Y  Planning  Fleet 

2  Y  Compartment  Measure 


Model  Datatype 


2  Y  Compartment  Measure  f  leetcapmeasure 

3  Allocated  Fleet  Capacity  f leetcapacity 

4  fleets imremain 

5  fleetsimflag 


PLANFLT 

MEASURE 

Long>=0 


Long+/- 


Planning  fleet 

Unit  of  measure  for  the  dynamic  capacity 
constraint  for  this  fleet 

Yes  mton-mi/hr  Dynamic  vehicle  capacity  allocated  for  the 
planning  fleet,  measured  in  compartment 
capacity  times  speed  throughput  units,  such 
as  mton-mi/hr,  sqft-mi/hr,  etc. 

Fleet  dynamic  throughput  capacity  available 
for  simulation,  may  go  negative  temporarily 
since  trips  are  not  interrupted  in  mid¬ 
route 

Fleet  simulation  flag  used  in  the  model 


PLNFLTTR  Edit  Limits  Specifies  the  allowable  fleet  to  fleet  transfers 

Plan  Fleet  Transfer  Keys  Full 


#  K?  Field  Name 


1  Y  From  Planning  Fleet 

2  Y  To  Planning  Fleet 

3  Allow  Cargo  Transfers? 


Model  Datatype 


allow  transfers 


Domain | Lookup  B|V  Unit  Meas  Description 


PLANFLT  The  from  pl< 

transfer 

PLANFLT  The  to  plain 

trains  fer 

Yesflag  Marked  Yes  : 


The  from  planning  fleet  in  a  fleet  to  fleet 
transfer 

The  to  planning  fleet  in  a  fleet  to  fleet 
trains  fer 

Marked  Yes  if  the  model  should  allow  cargo 
transfers  between  the  fleets 


REJREAS 

Rejection  Reason 


#  K?  Field  Name 


1  Y  Cargo  Number 

2  Y  Rejection  Type 

3  Rejection  Count 


Edit  Limits  Lists  cargos  delayed  and  a  count  of  candidate  vehicle  rejections  by  vehicle  type 
Output 


Model  Datatype 

i  _ 


re j  erg 
re j  count 


Domain | Lookup  B|V  Unit  Meas  Description 


CARGO 
REJTYPE 
Short >=0 


Cargo  number  that  is  delayed  or  rejected 
Rejection  reason  type 
Count  of  rejections  for  this  cargo  and 
rejection  reason  type 


REQCLASS  E 

Requirement  Class 


#  K?  Field  Name 

I _ I _ 

1  Y  Requirement  Class 


Edit  Limits  Lists  the  aggregated  requirement  classes  for  calculating  summary  cargo  delivery  versus 
required  totals  for  reports 


Model  Datatype 


Domain  I  Lookup  B|V  Unit  Meas  Description 
J _ _ 1 I — l - 1 - 


A15  Aggregated  : 


Aggregated  requirement  class  for 
calculating  summary  cargo  delivery  versus 
required  totals  for  reports 


REQFAC 

Edit  Limits 

Calculated  table  listing  the  facilities  that  a  requirement  improves 

Req  Facility  Change 

Output 

#  K?  Field  Name 

■  i 


1  Y  Requirement 

2  Y  Node 

3  Y  Facility 

4 

REQFLEET 
Required  Fleet 


#  K?  Field  Name 


1  Y  Requirement  Type 


Model  Datatype 


reqfacility 


firstreqimprv 


Domain | Lookup } B | V  ^  Unit  Meas  ^ Description 

REQUIRE  A  requireme: 

capacity  wh< 

FACILITY  The  target  3 


FACILITY 

REQIMPRV 


A  requirement  which  modifies  the  facility 
capacity  when  deliverd 

The  target  node  whose  facility  capacity 
changes  after  complete  delivery  of  the 
requirement 

The  target  facility  whose  capacity  changes 
after  complete  delivery  of  the  requirement 
First  pointer  to  the  improvements 
associated  with  this  requirement  and 
facility 


Edit  Limits  Defines  the  allowable  fleets  by  mode  for  a  requirement  type,  if  the  requirement  type  is 
restricted  to  certain  fleets 


Model  Datatype 


Domain | Lookup  B | V  ^ Unit  Meas  Description 


REQTYPE  Requirement 


2  Y  Transport  Mode  reqfleetmode 

3  Y  Allowable  Planning  Fleet  reqfleet 


MODE 

PLANFLT 


Requirement  type  which  has  restricted 
allowable  fleets 

Transport  mode  with  restricted  fleets 
Allowable  planning  fleet  for  this 
requirement  type  and  transport  mode 
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Directory  Type :  Scenario 


REQIMPRV 

Req  Fac  Cap  Change 

Edit  Limits 

Defines  how  the  delivery  of  a  requirement  improves  facility  throughput 

#  K?  Field  Name 

Mode 

i 

»1  Datatype  Domain | Lookup ( B | V ^ Unit  Meas 

Description 

j - - - 

1  Y  Requirement 

2  Y  Node 

REQUIRE 

FACCAP 

A  requirement  which  modifies  the  facility 
capacity  when  deliverd 

The  target  node  whose  facility  capacity 
changes  after  complete  delivery  of  the 

3  Y  Facility 

4  Y  Throughput  Measure 

5  Throughput  Change 

6 


FACCAP 

FACCAP 

faccap_change  Long>=0 

faccap_change_meas  MEASURE 


requirement 
The  target  facility  whose  capacity  changes 
after  complete  delivery  of  the  requirement 
A  throughput  measure  whose  capacity  is 
changed  after  complete  delivery  of  the 
requirement 

The  amount  of  throughput  change  at  this 
facility  in  the  appropriate  units  of 
measure 

The  throughput  measure  record  in  the 
MEASURE  table 


REQLAG  Edit 

Requirement  Link  Lag 


Limits  Defines  timing  links  between  delivery  of  independent  and  dependent  requirements 


#  K?  Field  Name 
I _ 1 - ; - 


Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 


1  Y  Dependent  Req  Id 

2  Y  Independent  Req  Id 

3  Min  Lag  Days 


dependent_req 

independent_req 

reqminlag 


REQUIRE 

REQUIRE 

DaysDelayToHr 


day  (hr) 


Dependent  requirement  identifier  whose 
delivery  must  come  after  delivery  of  one  or 
more  independent  requirements 
Independent  requirement  identifier  whose 
delivery  must  come  before  delivery  of  one 
or  more  dependent  requirements 
Minimum  lag  time  after  the  predecessor 
requirement  is  delivered  before  which  the 
successor  requirement  should  not  be 
delivered 


4  Target  Lag  Days 

reqlag 

DaysDelayToHr  day  (hr) 

Target  lag  time  after  the  predecessor 
requirement  is  delivered  before  which  the 
successor  requirement  should  not  be 
delivered 

REQMISS 

Required  Mission 

Edit 

Limits 

Lists  special 

missions  for  requirements,  cargo  classes,  and  modes 

#  K?  Field  Name 

Model  Datatype 

i 

Domain  1  Lookup  B|V  Unit  Meas 

j Description 

1  Y  Requirement  Id 

2  Y  Cargo  Class 

3  Y  Mode 

4  Special  Mission 

reqmissclas 

reqmissmode 

reqmiss 

REQUIRE 

CARGCLAS 

MODE 

MISSION  Yes 

Movement  requirement  having  a  special 
mission 

Cargo  class  to  which  the  special  mission 
applies  (Dry,  Pax,  etc.) 

Transport  mode  to  which  the  special  mission 
applies 

Special  mission  for  this  requirement,  cargo 
class,  and  transport  mode 

REQMODE 

Required  Mode 

Edit 

Limits 

Lists  excluded  modes  for  specific  requirements  and  cargo  classes 

#  K?  Field  Name 
|  1 

Model  Datatype 

i 

Domain | Lookup Blv^ Unit  Meas 

Description 

1  Y  Requirement  Id 

2  Y  Cargo  Class 

reqmodeclas 

REQUIRE 

CARGCLAS 

Movement  requirement  having  a  mode 
exclusion 

Cargo  class  for  which  the  mode  exclusion 
applies 

Excluded  mode  for  this  requirement  and 
cargo  class 

3  Y  Excluded  Mode 

reqmodeexcl 

MODE 

REQNIMPR 

Req  Node  Cap  Change 

Edit 

Limits 

Defines  how  the  delivery  of  a  requirement  improves  node  throughput 

#  K?  Field  Name 

I  1 

( Model  Datatype 

^ Domain | Lookup ( B 1 v ( Unit  Meas 

Description 

1  Y  Requirement 

2  Y  Node 

REQUIRE 

NODECAP 

A  requirement  which  modifies  the  node 
capacity  after  arrival 

The  target  node  whose  capacity  changes 
after  complete  delivery  of  the  associated 

3  Y  Throughput  Measure 

4  Throughput  Change 

5 


NODECAP 

nodecap_change  Long>=0 

node  c  ap_c  hang  e_mea  s  MEASURE 


requirement 
A  throughput  measure  whose  capacity  is 
changed  after  complete  delivery  of  the 
requirement 

The  amount  of  throughput  change  at  this 
facility  in  the  approriate  units  of  measure 
A  throughput  measure  record  in  the  MEASURE 
table 
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Directory  Type :  Scenario 


REQNODE 
Required  Node 


Edit  Limits 


Lists  required  intermediate  POE  or  POD  nodes  or  ports  for  movement  requirements  with 
specified  staging,  POE/POD  time  frames,  and  mode  of  transport  if  desired _ 


¥  K?  Field  Name 


Model  Datatype 


Domain | Lookup ( B | V  ^  Unit  Meas  ^ Description 


Y  Requirement  Id 

Y  Cargo  Class 

reqnodeclas 

REQUIRE 

CARGCLAS 

Y  LAD 

reqlatetim 

DayToHr 

day  (hr) 

EAD 

reqearlytim 

DayToHr 

day  (hr) 

Required  Node 

reqnode 

NODE 

Yes 

Required  Mode  to  Node 

reqnodemode 

MODE 

Required  Config  to  Node 

reqnodecfg 

CARGCONF 

Stage  Name 

reqstage 

STAGE 

Description 

A50 

Movement  requirement  identifier  with 
intermediate  ports  or  staging 
Cargo  class  for  which  the  required  node 
applies 

Latest  arrival  day  at  this  required  port 
node  (the  LAD  is  used  to  determine  the 
order  in  which  required  nodes  are  visited) 
Earliest  arrival  day  at  this  required  port 
node,  if  any 

Required  intermediate  POE/POD  node  or  port 
for  this  movement  requirement 
Required  transport  mode  specified  for 
delivery  to  the  intermediate  node,  if  any 
(blank  permits  the  use  of  any  mode  for 
delivery) 

Required  configuration  specified  for 
delivery  to  the  intermediate  node,  if  any 
(blank  permits  the  use  of  any 
conf igurat ion ) 

Staging  deployment  name  if  multiple 
requirements  are  staged  together  at  this 
node  (the  STAGE  record  must  have  the  same 
node  as  in  REQNODE) 

Description  of  this  intermediate  node,  e.g. 
consolidation,  container  stuffing,  mode 
change,  re -configuration,  combat  loading, 
etc. 


REQNOIM  Edit  Limits 

Req  Node  Improved  Output 

Calculated  list  of  requirements  which  improve  node  throughput 

#  K?  Field  Name  Mode 

»1  Datatype  Domain | Lookup (B | V(Unit  Meas  ^ Description 

1  Y  Requirement  REQUIRE  A  requirement  which  modifies  the  node 

capacity  when  fully  delivered 

2  Y  Node  reqnode  improved  NODE  The  target  node  whose  capacity  changes 

after  complete  delivery  of  the  requirement 

3  f ir s treqnoimpr  REQNIMPR  First  pointer  to  the  node  improvements 

associated  with  this  requirement 

REQQUAN  Edit  Limits 

Requirement  Quantity 

Provides  quantity  data  for  each  movement  requirement  and  cargo  category 

#  K?  Field  Name  Model  Datatype  Domain | Lookup  B|V  Unit  Meas  Description 

1  Y  Requirement  Id  REQUIRE  Requirement  identifier  for  the  cargo 

2  Y  Cargo  Category  reqeatmeas  CATMEAS  Cargo  category  which  describes  the  kind  of 

cargo  being  transported 

3  Y  Cargo  Measure  CATMEAS  Dimensional  measure  for  this  requirement 

a  and  cargo  category 

4  Quantity  reqqn  reqqn  Yes  Q  Requirement  category  quantity  or  dimension 

in  this  unit  of  measure 

5  heapreqeat  REQQUAN  Heap  sort  order  for  this  requirement 

quantity  prior  to  mode  planning 

REQRET  Edit  Limits 

Requirement  Return 

Lists  requirement  return  or  transfer  days,  if  any,  for  removing  requirements  from  a 
theater  and  eliminating  its  supply  consumption  and  pax  regeneration 

#  K?  Field  Name  Model  Datatype  Domain | Lookup  B|V  Unit  Meas  Description 

1  Y  Requirement  Id 

2  Return  Day  req: 

REQUIRE  Requirement  identifier  that  is  returned  or 

leaves  the  theater  after  delivery 

ret  DayToHr  day  (hr)  Requirement  return  day  or  departure  day 

when  it  leaves  the  theater 

REQTYPE 

Requirement  Type 


Edit  Limits 


Provides  data  about  requirement  types  or  unit  types 


#  K?  Field  Name 
\  -i - 


Model  Datatype 


Domain ! Lookup  B|V  Unit  Meas  Description 

_] _ I -  1  1 - 1 - - 


1  Y  Requirement  Type 

2  Requirement  Class  reqclas 


3  Service  reqservice 

4  Planning  Horizon  Days  reqlook 

5  Assembly  Delay  Days  reqassdel 

6  RLD  Packaging  Range 


A15 

REQCLASS 


Yes 


SERVICE  Yes 

DaysDelayToHr  day  (hr) 


DaysDe layToHr 


DayToHr 


day  (hr) 


day  (hr) 


Requirement  type  or  unit  type 

Aggregated  requirement  class  for 

calculating  summary  cargo  delivery  versus 

required  totals  for  reports 

Service  for  this  requirement  type  or  unit 

type 

Planning  or  look-ahead  horizon  m  days  for 
scheduling  cargos  of  this  requirement  type 
prior  to  their  target  lift  date 
Additional  assembly  delay  days  needed  after 
delivery  at  the  destination  used  to 
calculate  closure  and  lateness  relative  to 
the  RDD 

Packaging  range  for  merging  movements  with 
similar  Ready  to  Load  Dates  (RLDs) 
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Directory  Type:  Scenario 


REQTYPE 

Requirement  Type 
#  K?  Field  Name 


Edit  Limits  Provides  data  about  requirement  types  or  unit  types 


Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 


7  RDD  Packaging  Range 

8  RDD  Tolerance 


9  Max  Days  Late 


maxlateness 


10  Cargo  Lateness  Penalty  reqlatepen 


11  Penalty/Benefit  Cut-off  reqcutoff 


12  Early  Assignment  Level  reqthresh 


13  Regeneration  Delay  Days  regendel 


14  Default  Priority  Order  reqtyporder 


15  Minimum  Cargo  Load  %  reqminld 


DayToHr 

DaysDelayToHr 


DaysDelayToHr  Yes  day  (hr) 


Long>=l 


DaysDelayToHr 


16  Integrity  Benefit 


17  Is  Resupply? 


integrity_benef it  DaysDelayToHr 


is_re supply 


firstsuppcons 

listexreqtyp 

firstreqfleet 


Yesflag 


REQFLEET 


day  (hr)  Packaging  range  for  merging  movements  with 
similar  Required  Delivery  Dates  (RDDs) 
day  (hr)  Days  tolerance  for  lateness  at  the 

destination  relative  to  the  RDD  before  mode 
planning  increases  delivery  cost  to  reduce 
lateness 

day  (hr)  Days  late  relative  to  the  target  delivery 
date  beyond  which  a  cargo  is  rejected  in 
scheduling  and  is  reported  with  rejection 
reasons,  even  if  the  penalty  is  acceptable 
. 01$/Q-day  Penalty  for  cargo  ton-days  of  lateness  (as 
compared  with  vehicle  usage  penalties)  in 
the  scheduling  algorithm 

$/$  Cost  cut  off  level  above  which  a  potential 

cargo  assignment  is  rejected  early  in  the 
multi -port  scheduling  algorithm  (blank  or  a 
large  value  means  no  cutoff) 

$/$  Threshold  penalty/benefit  level  below  which 

a  potential  cargo/ship  assignment  is 
accepted  immediately  in  the  multi-port 
scheduling  algorithm  (a  large  value  reduces 
run  time  but  may  make  a  selection  before 
costing  a  preferred  vehicle) 
day  (hr)  Nonzero  delay  days  to  regenerate  attritted 
cargo  for  this  requirement;  cargo  is 
regenerated  with  the  same  data  as  the 
original  movement  (blank  means  no 
regeneration) 

Default  priority  order  for  this  requirement 
type  if  not  specified  for  a  given 
requirement  (1  is  the  earliest  priority 
order;  blank  is  treated  as  no  priority  or 
as  99) 

%  Minimum  %  split  of  a  single  cargo  (i.e. 

requirement+category)  for  assigning  to  a 
separate  non-airlift  trip  (not  used  for 
airlift;  100%  prevents  any  non-airlift 
splitting;  this  is  separate  from  the 
Minimum  Cargo  Load  %  and  Minimum  Vehicle 
Load  %  in  PARAM) 

day  (hr)  Wait  days  benefit  indicating  a  preference 

for  loading  identical  Requirement  Id*s  onto 
the  same  vehicle  trip 

Yes  if  this  requirement  type  is  dynamically 
ordered  by  other  requirements  in  the 
theater,  when  dynamic  resupply  is  being 
modeled 

First  consumption  rate  for  this  requirement 
type 

List  of  exclusions  for  this  requirement 
type,  if  any 

First  allowable  requirement  fleet  record 
for  this  requirement  type 


REQUIRE  Edit  Limits  Provides  information  about  each  movement  requirement  or  package 

Requirement  to  Move  _ _ 


#  K?  Field  Name  Model  Datatype  Domain | Lookup  B|V  Unit  Meas  Description 


#  K?  Field  Name 
I - 1 - 

1  Y  Requirement  Id 

2  Major  Unit 

3  Origin 

4  Destination 

5  RLD 


8  Computed  Closure  Day 


9  Priority  Order 


10  Supply  Requirement  Id 


reqmajunit 

reqorig 

reqdest 

readytim 

reqdeltim 


earlydel 


reqpriority 


A15 

MAJUNIT 

NODE 

NODE 

DayToHr 

DayToHr 


DayToHr 


DayToHr 


day  (hr) 
day  (hr) 


day  (hr) 


day  (hr) 


reqtotal 


Long>=0 


Movement  requirement  or  package  id 
Major  unit  associated  with  this  movement 
requirement 

Starting  origin  of  the  requirement 
Final  destination  of  the  requirement 
Ready  to  load  day  or  earliest  day  the 
requirement  is  available  at  its  origin 
Required  delivery  day  of  the  packaged 
requirement  at  its  destination  including 
time  for  assembly 

Earliest  allowed  delivery  day  of  the 
requirement  at  its  destination  prior  to 
assembly 

Closure  day  for  the  requirement  based  on 
the  closure  minimum  %  requirement  specified 
in  the  MajUnit  table 
Relative  priority  order  for  this 
requirement  as  a  secondary  sort  after  the 
Target  Lift  Date  (one  means  first  priority 
in  assigning  lift  assets,  blank  defaults  to 
the  priority  order  of  the  requirement  type) 
Supply  requirement  identifier  in  the 
SUPPREQ  table,  when  this  requirement  has 
been  generated  as  either  static  or  dynamic 
resupply 

Total  quantity  for  this  requirement 


11 
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Directory  Type :  Scenario 


REQUIRE 

Requirement  to  Move 


#  K?  Field  Name 


Edit  Limits  I  Provides  information  about  each  movement  requirement  or  package 


^ Model  Datatype 
listcrgclose 


firstreqmode 
firstreqmiss 
first reqquan 
firstreqlag 

firstreqnode 

firstreqret 

firstreqcat 

f irstreqfac 

running_total 

listreqvflt 

f irstreqnoim 


Domain | Lookup  B|v  Unit  Meas  Description 


REQMODE 

REQMISS 

REQQUAN 

REQLAG 


Long>=0 


REQNOIM 


quantity 


Initially  a  list  of  requirement  lag  links 
with  different  predecessors  for  this 
successor;  at  the  end,  a  list  of  terminal 
cargos  arriving  at  the  final  destination 
sorted  in  order  of  end  unload  day  for 
computing  closure  of  the  requirement 
First  requirement  excluded  mode 
First  requirement  special  mission 
First  cargo  for  this  requirement 
First  successor  requirement  with  a  lag 
relative  to  this  predecessor  requirement 
First  required  node  or  port  stop  for  this 
movement  requirement 
First  (and  only)  return  day  for  this 
movement  requirement 

First  requirement  category  pair  for  this 
movement  requirement 

First  requirement  facility  improvement  pair 

for  this  requirement 

A  running  total  of  cargo  quantities 

delivered  for  this  requirement 

List  of  lift  assets  delivered  with  the 

requirement 

First  requirement  node  impromvement  pair 
for  this  requirement 


ROUTE 

Route  Distances 


Edit  Limits 
Output 


Outputs  a  summary  distance  matrix  calculated  by  the  model  and  used  during  scheduling 


#  K? 

1  1 

Field  Name 

Model  Datatype 

i 

t Domain | Lookup ( B | V  ^  Unit  Me 

1  Y 

Route  From  Node 

route_from_node 

NODE  Yes 

2  Y 

Route  To  Node 

route_to_node 

NODE  Yes 

3  Y 

Route  Type 

route_type 

ROUTTYPE  Yes 

4  Y 

Vehicle  Is  Empty? 

vehi c 1 e_i s_emp t y 

Yesflag 

5 

Distance 

route_distance 

Short >=0 

nmi 

6 

Total  Delay 

route_delay 

HoursDelay 

hours 

7 

Critical  Leg 

route_critical_leg 

Short >=0 

nmi 

8 

Payload  Percentage 

rout  e__pay  load 

% 

% 

9 

Attrit  Daily  Rate 

route_attrition 

Short >=0 

%%/day 

10 

Attrit  Probability 

rout e_probabi 1 i t y 

0,9999 

%% 

11 

route_convoy 

CONVOY 

12 

nextroute 

ROUTE 

13 

firs trout ecap 

ROUTECAP 

ROUTEXCL 
Route  Exclusion 


#  K?  Field  Name 

I  I 


1  Y  Route  Type 

2  Y  Excluded  Refuel 


route  from  node  NODE  Yes  Begining  node  for  the  computed  port-to-port 

“  route  distance 

route  to  node  NODE  Yes  Ending  node  for  the  computed  port-to-port 

route  distance 

route  type  ROUTTYPE  Yes  The  type  of  route 

?  vehicle  is  empty  Yesflag  Yes  if  the  route  is  computed  using  an  empty 

_  “  vehicle  (such  routes  are  computed 

separately  only  if  the  vehicle  has  a 
payload  that  depends  on  critical  leg) 
route_distance  Short>=0  nmi  The  route  distance  in  nautical  miles 

route  delay  HoursDelay  hours  The  additional  route  delay  in  hours, 

including  the  cumulative  effects  of 
individual  link  delays,  refueling  stops, 
link  speed  limits,  and  link  speed  changes 

route  critical  leg  Short>=0  nmi  The  critical  leg  distance,  which  is  the 

“  longest  distance  between  refueling  stops 

(including  recovery  legs  if  refueling  is 

excluded  at  the  POD) ,  in  nautical  miles 

?e  route  payload  %  %  The  percentage  of  the  total  cargo  payload 

listed  in  VehData  that  is  permitted 
associated  on  this  route  based  on  the 
critical  leg  distance 

=»  route  attrition  Short>=0  %%/day  The  effective  overall  attrition  rates  of 

~  the  route,  based  on  the  probability 

convolution  of  the  individual  link 
attrition  rates 

ty  route  probability  0,9999  %%  The  cumulative  probability  of  discrete 

attrition  on  this  route  based  on  the  node 
attrition  probabilities 

route  convoy  CONVOY  Convoy  record,  if  any,  associated  with  this 

—  '  route 

nextroute  ROUTE  Next  pointer  for  lists  of  routes 

f irs trout ecap  ROUTECAP  First  pointer  to  a  group  of  pointers  to 

capacitated  links  for  this  route 


Edit  Limits  Lists  excluded  facility  types  for  refueling  on  the  various  route  types 


Model  Datatype 


Fac  Type  routfactypexcl 


Domain | Lookup  B  |  V  Unit  Meas  Description 


ROUTTYPE 

FACTYPE 


Route  type  for  computing  vehicle  paths 
Excluded  facility  type  for  refueling  on  the 
route  type 


ROUTLINK 

Edit  Limits 

Lists  the  links  used  by  routes  in  the  RouteOut  distance  matrix 

Route  Links  Used 

Output 

#  K?  Field  Name 


1  Y  Link  From  Node 

2  Y  Link  To  Node 

3  Y  Link  Mode 


Model  Datatype 


route  link 


Domain | Lookup  B|V  Unit  Meas  Description 


From  node  for  this  transport  link  which  is 
used  by  the  routes  listed  in  RouteOut 
To  node  for  this  transport  link  which  is 
used  by  the  routes  listed  in  RouteOut 
Transport  mode  for  this  route  link 
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Directory  Type :  Scenario 


ROUTTYPE 
Route  Type 


Edit  Limits  Provides  route  type  data  for  determining  vehicle  paths,  including  refueling  range, 
refueling  facility  requirements,  and  payload  versus  critical  leg 


#  K?  Field  Name 


Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 


1 

Y  Route  Type 

A15 

2 

Transport  Mode 

rtmode 

MODE 

Yes 

3 

Speed  to  Convert  Delays 

rtspd 

1,999 

Yes  nmi/hr 

4 

Range  at  Max  Payload 

mg 

Short>=l 

nmi 

5 

Payload  Decrease  %/kmi 

rngchg 

0,999 

%/1000nmi 

6 

Refuel  Arrive/Depart  Time 

ref ue larr dept im 

Hour 

hr 

7 

Refuel  Time 

refueltim 

HoursDelay 

hr 

8 

Required  Link  Rating 

rtlinkrating 

0,9999 

9 

Refuel  Fac  Length  Req. 

refuellen 

Short >=0 

ft 

10 

Refuel  Fac  Width  Req. 

refuelwid 

0,999 

ft 

11 

Refuel  Fac  Dimension  Req. 

refueldim 

0,999 

varies 

12 

Refuel  Fac  Rating  Req. 

refuelrating 

Short >=0 

varies 

13 

f irs trout excl 

ROUTEXCL 

14 

emptmg 

Short >=0 

15 

refueltottim 

HoursDelay 

hr 

Route  type  for  computing  vehicle  paths 
Transport  mode  for  this  route  type 
Nominal  routing  speed  which  is  used  to 
convert  link  delays  and  refueling  delays  to 
equivalent  distances  for  routing,  in 
nautical  mph 

Range  or  critical  leg  distance 
corresponding  to  the  maximum  allowed 
payload,  in  nautical  miles 
Percent  decrease  in  payload  per  1000 
nautical  miles  of  increase  in  critical  leg 
distance  beyond  the  max  payload  range 
Arrival  and  depart  time  delays  for 
refueling  (e.g.,  landing  and  takeoff 
delays) 

Refueling  time  in  the  facility 
User- definable  link  rating  required  for 
each  link  in  a  feasible  path  for  this  route 
type;  for  example,  for  sealift  the  Required 
Link  Rating  may  represent  ship  draft,  which 
cannot  exceed  the  Link  Rating  (link  draft) 
of  any  link  on  a  feasible  path 
Facility  length  required  for  refueling 
Facility  width  required  for  refueling 
Facility  dimension  required  for  refueling 
(e.g.,  draft  for  sea) 

Facility  rating  level  required  for 
refueling  (e.g.,  LCN  or  landing 
classification  number  for  air,  boom 
capacity  for  sea) 

First  facility  type  exclusion  for  refueling 
on  this  route  type 

Max  empty  vehicle  range  calculated  from  the 
payload  decrease  down  to  zero  payload 
Total  refuel  time  including  arrive  and 
depart  time 


RPTCARGO 
Cargo  Link 


Edit  Limits 
Output 


LiXSuS  muxti-moaax  cargo  moveineaus  x 
predecessor/successor  relationships 


#  K?  Field  Name 

l _ I _ 


Model  Datatype 


Domain | Lookup  B|v  Unit  Meas  Description 


1 

Y  Cargo  Split  Id 

A50 

2 

Cargo  Number 

CARGO 

3 

Requirement  Id 

REQUIRE 

4 

Cargo  Category 

CARGO CAT 

5 

Cargo  Configuration 

CARGCONF 

6 

Cargo  Type 

CARGTYPE 

7  Cargo  Basic  Quantity 

reqqn 

Q 

8  Begin  Load  Day 

DayToHr 

day 

9  End  Load  Day 

DayToHr 

day 

10  Begin  Unload  Day 

DayToHr 

day 

11 

End  Unload  Day 

DayToHr 

day 

12 

Cargo  Predecessor 

CARGO 

13 

Arrive  POE 

DayToHr 

day 

14 

POE 

FACILITY 

15 

POE  Facility 

FACILITY 

16 

Depart  POE 

DayToHr 

day 

17 

Arrive  POD 

DayToHr 

day 

18 

POD 

FACILITY 

19 

POD  Facility 

FACILITY 

20 

Depart  POD 

DayToHr 

day 

21 

Vehicle 

VEHICLE 

22 

Number  of  Vehicle  Trips 

Long>=0 
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Cargo  split  identifier  for  this  report 
Cargo  or  shipment  number 
Movement  requirement  or  package  id 
Cargo  category  which  describes  the  kind  of 
cargo  being  transported 
Cargo  configuration  which  is  used  to 
package  the  cargo  for  transport  on  one  or 
more  modes 

Mode- specific  cargo  type  which  groups  cargo 
categories  for  a  given  transport  mode  in 
order  to  define  stow  factors,  load  rates, 
and  load  compatibility  for  vehicle 
compartments 

Cargo  quantity  in  the  basic  unit  of  measure 
for  its  cargo  class  (ston,  pax,  cbbl) 

Day  that  the  cargo  begins  loading  (in  the 
model,  this  is  also  the  earliest  possible 
load  time  based  on  RLD  or  predecessor  cargo 
or  earliest  theater  depart,  until  the  cargo 
is  simulated) 

Day  that  the  cargo  completes  loading 
Day  that  the  cargo  begins  offloading  (in 
the  model,  this  is  also  the  earliest 
possible  unload  time  until  the  cargo  is 
simulated) 

Day  that  the  cargo  completes  offloading  (in 
the  model,  this  is  also  crgtdd,  the  Target 
Delivery  Date  until  the  cargo  is  scheduled) 
Unique  predecessor  cargo  which  immediately 
precedes  this  cargo  and  carries  the  same 
requirement  (zero  for  an  origin  cargo) 

Day  cargo  arrives  at  POE 
POE  node 

POE  facility  name 
Day  cargo  departs  POE 
Day  cargo  arrives  at  POD 
POD  node 

POD  facility  name 

Day  cargo  departs  POD 

Vehicle  assigned  to  this  trip 

Number  of  vehicle  trips  assigned  to  this 

trip 


Directory  Type :  Scenario 


RPTFACIL 
Report  Facility 


#  K?| Field  Name 

1  Y  Facility  Node 

2  Y  Facility  Name 

3  Y  Stop  Number 

4  Y  Cargo  Number 

5  Facility  Type 


6  Max  Vehicles  Per  Hour 


Edit  Limits  Provides  a  report  on  facility  cargo  loading  and  offloading  combining  the 
Output  Facility, Stop, Cargo, Trip  tables  _ 


Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 


FACILITY 

FACILITY 

STOP 

CARGO 

FACTYPE 


7  Max  Parking 


8  Operating  Hours /Day 

9  Arrive  Day 

10  Depart  Day 

11  Is  Unload? 

12  Hours  Wait  for  Facility 

13  Trip  Number 

14  Vehicle 

15  Requirement  Id 

16  Cargo  Category 

17  Cargo  Type 

18  Cargo  Basic  Quantity 

19  Basic  Quantity  Measure 

20  Begin  Load  or  Unload  Day 

21  End  Load  or  Unload  Day 

22  Cargo  Predecessor 


DayToHr 

DayToHr 

Yesflag 

HoursDelay 


REQUIRE 

CARGOCAT 


CARGTYPE 

reqqn 


DayToHr 

DayToHr 


Node  with  one  or  more  facilities 

Facility  name  at  this  node 

Unique  stop  number  for  this  port  or  node 

facility  visit 

Cargo  or  shipment  number 

Facility  type  for  this  facility  (if  blank, 
this  facility  can  handle  all  transport 
modes  for  which  no  facility  is  defined) 
veh/hr  Maximum  combined  vehicle  arrivals  and 

departures  per  hour  which  can  be  handled  in 
this  facility  during  its  hours  of  operation 
veh  Maximum  number  of  " standard"  vehicles 

permitted  in  the  facility  at  the  same  time, 
e.g.  MOG  for  airlift  or  number  of  berths 
for  sealift  (vehicle  types  may  weighted  by 
an  equivalence  factor  to  convert  to  a 
standard  vehicle) 

hr/day  Operating  hours  per  day  that  the  facility 
is  open 

day  (hr)  Arrive  day  at  the  stop  port 
day  (hr)  Depart  day  from  the  stop  port 

"Yes"  flag  to  indicate  that  a  stop  is  for 
unloading,  otherwise  blank 
hr  Hours  vehicle  spent  waiting  for  port 

facilities 

First  stop  arrive  day  of  the  trip 
associated  with  this  stop 

Aircraft  assigned  to  this  trip  (flight)  if 
airlift 

Requirement  identifier  for  this  cargo 
Cargo  category  which  describes  the  kind  of 
cargo  being  transported 
Cargo  type  for  this  cargo 

Q  Cargo  quantity  in  the  basic  unit  of  measure 

for  its  cargo  class  (ston,  pax,  cbbl) 

Cargo  quantity  basic  measure  (ston,  pax, 
cbbl) 

day  (hr)  Day  that  the  cargo  begins  loading  or 
unloading  at  the  stop 

day  (hr)  Day  that  the  cargo  ends  loading  or 
unloading  at  the  stop 

Unique  predecessor  cargo  which  immediately 
precedes  this  cargo  and  carries  the  same 
requirement  (zero  for  an  origin  cargo) 


RPTFCAP  Edit  Limits  Provides 

Report  Facility  Cap  Output 


a  summary  of  facility  capacity  status  over  time 


#  K?  Field  Name 

1 _ I - 

1  Y  Facility  Node 

2  Y  Facility  Name 

3  Y  Facility  Capacity  Measure 

4  Y  Day 


5  Daily  Capacity  Available  rptfcapavl 


t Model  Datatype 
rptfcap 


rptfcapday 


Domain | Lookup  B|v  Unit  Meas  Description 


6  Daily  Capacity  Used 


7  Hours  at  Saturation 


rptfcapused 


rptfcapsat 


FACCAP 

FACCAP 

FACCAP 

simendday 

Long>=0 


Long>*0 


Node  with  one  or  more  facilities 
Facility  name  at  this  node 
Throughput  measure  for  this  facility  (ston 
throughput,  ston  storage,  etc.) 
day  (hr)  Day  at  which  a  change  in  facility  resources 
or  capacity  changes 

Q  Daily  total  capacity  available  summed  over 

all  hours  of  operation  for  throughput,  or 
ending  capacity  for  storage 
Q  Daily  total  capacity  utilized  summed  over 

all  hours  of  operation  for  throughput,  or 
ending  stored  capacity  for  storage 
hr  Number  of  hours  in  the  day  during  which 

this  facility  capacity  measure  is  saturated 


RPTFVEH  Edit  Limits 

Report  Facility  Veh  Output 


Provides  a  summary  of  facility  vehicle  throughput  over  time 


#  K?  Field  Name 


^ Model  Datatype 
rptfvehfac 


1  Y  Facility  Node  rptfvehfac 

2  Y  Facility  Name 

3  Y  Facility  Capacity  Measure  rptfvehmeas 


4  Y  Day 


rptfvehday 


5  Max  Available  Capacity  rptfvehavail 


6  Utilized  Capacity 


Hours  at  Saturation 


rptfvehutil 

rptfvehsat 


Domain | Lookup  B|V  Unit  Meas  Description 


FACILITY 

FACILITY 

MEASCLAS 


simendday 

Long>=0 

Long>=0 


Node  with  one  or  more  facilities 
Facility  name  at  this  node 
Vehicle  throughput  measure  class  for  this 
facility  (number  of  "standard"  vehicle 
parking  spaces,  vehicles  per  hour,  etc,) 

day  (hr)  Day  at  which  a  change  in  facility  resources 
or  capacity  changes 

Q  Daily  total  capacity  available  summed  over 

all  hours  of  operation 

Q  Daily  total  capacity  utilized  summed  over 

all  hours  of  operation 

hr  Number  of  hours  in  the  day  during  which 

this  facility  is  saturated,  based  on  which 
capicity  was  limiting 
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Directory  Type :  Scenario 


RPTLATE 

Report  Lateness 


#  K?  Field  Name 


Edit  Limits  Summarizes  delivery  lateness  for  each  theater  and  basic  quantity  measure 
Output 


Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 


1  Y  Theater 

2  Y  Basic  Quantity  Measure 

3  Y  Lateness  Class 


Total  Quantity 


THEATER 

BASMEAS 


Long>=0 


Theater  name 

Basic  quantity  unit  of  measure  (ston,  pax, 
cbbl) 

Lateness  classification  for  reporting 
summary  lateness  (e.g.,  Ontime,  Scheduled, 
Unscheduled,  Within  1  Day  Late,  etc.) 

Total  quantity  for  the  theater,  basic 
measure,  and  lateness  classification 
Total  quantity  percent  for  the  theater, 
basic  measure,  and  lateness  classification 


RPTMEAS 

Report  Cargo  Meas 


#  K?  Field  Name 


Edit  Limits  Lists  the  user- selected  cargo  quantity  measures  to  be  used  in  the  RPTTOTAL  and  RPTTOTS 
cargo  delivery  reports,  selected  from  RPTMEASU 


1  Y  Cargo  Report  Measure 


Model  Datatype 

i  _ 


rptmeas 


Domain | Lookup  B|V  Unit  Meas  Description 


Select  / 


User-selected  cargo  quantity  measures  used 
for  the  RptMoe  and  Rpt Total  delivery 
profile  reports 
Selection  checkmark 


Edit  Limits  I  Lists  the  available  cargo  quantity  measures  for  the  RPTTOTAL  and  RPTTOTS  cargo  delivery 


I  Report  Cargo  Measure  Hide 


#  K?  Field  Name 

■  i 


1  Y  Cargo  Report  Measure 


reports,  extracted  from  CATMEAS 


Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 


Available  cargo  quantity  measures  for  the 
RptMoe  and  Rpt Total  delivery  profile 
reports 


RPTMOE 
Report  MOE 


#  K?  Field  Name 


Edit  Limits  Stores  the  cumulative  combat  effectiveness  MOE  profile  delivered  over  time  for  each 
Output  theater  and  Major  Unit 


Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 


1  Y  Theater 

2  Y  Major  Unit 

3  Y  Delivery  Day 

4  Cumulative  MOE  Required  cummoereq 


Cumulative  MOE  Delivered  cummoedel 


THEATER 
MAJUNIT 
simendday 
Short >=0 


Theater 
Major  unit 
Delivery  day 

Cumulative  MOE  quantity  required  by  this 
day  based  on  the  MOE  rating  for  each  major 
unit  in  the  MAJUNIT  table 
Cumulative  MOE  quantity  delivered  by  this 
day  based  on  the  MOE  rating  for  each  major 
unit  in  the  MAJUNIT  table 


Edit  Limits  Stores  the  cumulative  combat  effectiveness  MOE  profile  delivered  over  time  for  each 


Model  Datatype 


|  Report  MOE  Summary  Output 


#  K?  Field  Name 


1  Y  Theater 

2  Y  Requirement  Class 


3  Y  Delivery  Day 

4  Cumulative  MOE  Required  cummoereqsum 


Cumulative  MOE  Delivered  cummoedel  sum 


theater  summarized  by  Requirement  Class 


Domain | Lookup  B|V  Unit  Meas  Description 


THEATER 
REQ CLASS 

simendday 
Short >=0 


Theater 

Aggregated  requirement  class  for  computing 
summary  MOEs 
Delivery  day 

Cumulative  MOE  quantity  required  by  this 
day  based  on  the  MOE  rating  for  each  major 
unit  in  the  MAJUNIT  table 
Cumulative  MOE  quantity  delivered  by  this 
day  based  on  the  MOE  rating  for  each  major 
unit  in  the  MAJUNIT  table 


rPTREQ  Edit  Limits  Provides  calculated  summary  data  for  cargo  requirement  reports 

Report  Requirement  Output 


#  K?  Field  Name 

I  1 


1  Y  Requirement  Id 

2  Y  Basic  Quantity  Measure 

3  Y  Cargo  Number 

4  Major  Unit 

5  Require  Total  Quantity 

6  Origin 

7  Destination 


Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 


11  Computed  Closure  Day 


REQUIRE 

MEASURE 


CARGO 

MAJUNIT 


NODE 

NODE 

DayToHr 

DayToHr 


DayToHr 

DayToHr 


Movement  requirement  or  package  id 
Basic  unit  of  measure  for  reporting  (ston, 
pax,  cbbl) 

Cargo  or  shipment  number  or  package  id 
Major  unit  associated  with  this  movement 
requirement 

Summation  of  the  total  REQQUAN  quantity 
field  for  each  Requirement 
Starting  origin  of  the  requirement 
Final  destination  of  the  requirement 
Ready  to  load  day  or  earliest  day  the 
requirement  is  available  at  its  origin 
Required  delivery  day  of  the  packaged 
requirement  at  its  destination  (may  be 
adjusted  from  the  original  CINC  RDD) 
Earliest  allowed  delivery  day  of  the 
requirement  at  its  destination 
Closure  day  for  the  requirement  based  on 
the  closure  minimum  %  requirement  specified 
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Directory  Type :  Scenario 


Edit  Limits 
Output 


RPTREQ 

Report  Requirement 


¥  K?  Field  Name 


12  Priority  Order 


13  Delay  Days 


14  Cargo  Category 

15  Cargo  Type 

16  Cargo  Basic  Quantity 

17  Cargo  %  of  Requirement 

18  Begin  Load  Day 


19  End  Load  Day 

20  Begin  Unload  Day 

21  End  Unload  Day 


22  Is  Attritted? 

23  Attrit  Probability  %% 


24  Cargo  Predecessor 


25  Expected  Quantity 


Provides  calculated  summary  data  for  cargo  requirement  reports 


Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 


Day sDe 1 ayToHr 


CARGTYPE 

reqqn 


DayToHr 


DayToHr 

DayToHr 

DayToHr 


Yesf lag 


26  Days  Late 

RPTSTOP 
Report  Stops 


#  K?  Field  Name 


1  Y  Stop  Number 

2  Vehicle  Number 

3  Trip 

4  Trip  Start  Day 


Edit  Limits 
Output 


DaysDelayToHr  day 
Lists  the  vehicle  stop  itinerary 


in  the  REQTYPE  table 
Relative  priority  order  for  this 
requirement  as  a  secondary  sort  after  the 
Target  Lift  Date  (one  means  first  priority 
in  assigning  lift  assets,  blank  defaults  to 
the  priority  order  of  the  requirement  type) 
Assembly  delay  days  to  assist  in 
determining  the  Days  Late  when  added  to  the 
Unload  Day 

Cargo  category  which  describes  the  kind  of 
cargo  being  transported 
Cargo  type  for  this  cargo 

Cargo  quantity  in  the  basic  unit  of  measure 
for  its  cargo  class  (ston,  pax,  cbbl) 

Cargo  quantity  as  a  percent  of  the  total 
requirement  quantity  for  this  basic  measure 
Day  that  the  cargo  begins  loading  (in  the 
model,  this  is  also  crgtld,  the  Target  Lift 
Day  until  the  cargo  is  scheduled) 

Day  that  the  cargo  completes  loading 
Day  that  the  cargo  begins  offloading 
Day  that  the  cargo  completes  offloading  (in 
the  model,  this  is  also  crgtdd,  the  Target 
Delivery  Date  until  the  cargo  is  scheduled) 
Yes  if  the  cargo  is  attritted  in  the  last 
run  results,  blank  otherwise 
Calculated  cumulative  probability  of 
attrition  (in  %%  or  ten  thousandths)  for 
the  cargo  based  on  its  route  and  schedule 
and  including  the  attrition  of  predecessor 
cargos 

Unique  predecessor  cargo  which  immediately 
precedes  this  cargo  and  carries  the  same 
requirement  (zero  for  an  origin  cargo) 
Expected  delivery  quantity  for  display, 
computed  as  the  cargo  quantity  times  the 
attrition  probability 
Days  late  for  this  cargo 


Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 


STOP 

VEHICLE 

TRIP 

DayToHr 


Stop  number 
Vehicle  for  this  stop 
Trip  for  this  stop 

Trip  start  day  (first  arrive  day) ,  used  for 
sorting 


Daily  Supply  Storage  Output 


#  K?  Field  Name 


1  Y  Supply  Category 


2  Y  Supply  Node 

3  Y  Day 

4  Quantity  On  Hand 

5  Quantity  On  Order 

6  Order  Daily  Demand 

7  Order  Lead  Time 

8  Quantity  Ordered 

9  Order  Number 


Edit  Limits  |  Reports  the  daily  inventory  levels  at  each  supply  storage  site,  as  well  as  periodic 


order  quant it es 


Model  Datatype 

i 


rpt__supply_store 


Domain | Lookup  B|V  Unit  Meas  Description 


rpt_supp ly_day 

inventory 

on_order 

demand_rate 

lead_time 
quant ity_ordered 

order  number 


simendday 

Long+/- 

Long>=0 

Long>=0 

DayToHr 

Long>=0 

Long>-0 


Supply  cargo  category  which  ordered  and 
stored  at  a  terminal  by  the  dynamic 
resupply  model 

Storage  node  or  terminal  where  the  supply 
cargo  is  inventoried 

day  (hr)  Day  on  which  the  inventory  has  been  tracked 
Q  Inventory  level  for  this  day 

Q  Running  total  of  the  amount  that  has  been 

ordered  but  not  delivered  as  of  this  day 
Q/KCat/Day  Daily  demand  in  effect  on  this  day  based  on 
prior  arrivals 

day  (hr)  Estimated  lead  time  used  on  this  day 
Q  Basic  quantity  of  resupply  ordered  on  this 

day,  if  any 

Order  number  if  a  resupply  order  is  placed 
on  this  day 


RPTTOTAL 

Report  Total  Daily 


#  K?  Field  Name 


Edit  Limits 
Output 


Stores  the  daily  requirements  delivery  profile  by  Major  Unit  to  the  destination  from  the 
model  results 


1  Y  Theater 

2  Y  Major  Unit 

3  Y  Cargo  Measure 

4  Y  Delivery  Day 

5  Daily  Quantity  Required 

6  Daily  Quantity  Delivered 

7  Cumulative  Required 

8  Cumulative  Delivered 


Model  Datatype 


dayqnreq 

dayqndel 

cumqnreq 

cumqndel 


Domain | Lookup  B|v  Unit  Meas  Description 


THEATER 

MAJUNIT 

RPTMEAS 

simendday 

Long>=0 

Long>=0 

Long>*0 

Long>=0 


Theater 

Major  unit  for  this  total  delivery  record 
Cargo  quantity  measure 
Delivery  day 

Incremental  quantity  required  on  this  day 
Incremental  quantity  delivered  on  this  day 
Cumulative  quantity  required  by  this  day 
Cumulative  quantity  delivered  by  this  day 
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Directory  Type :  Scenario 


RPTTOTAL 

Edit  Limits 

Stores  the  daily  requirements  delivery  profile  by  Major  Unit  to  the  destination  from  the 

Report  Total  Daily 

Output 

model  results 

#  K?  Field  Name 


Model  Datatype 


^  Domain [ Lookup  t  B 1 v  t  Unit 


Meas  Description 


9 

Daily  %  Required 

dayperreq 

% 

% 

10 

Daily  %  Delivered 

dayperdel 

% 

% 

11 

Cumulative  %  Required 

cumperreq 

% 

% 

12 

Cumulative  %  Delivered 

cumperdel 

% 

% 

Incremental  %  of  total  major  unit  quantity 
required  on  this  day 

Incremental  %  of  total  major  unit  quantity 
delivered  on  this  day 

Cumulative  %  of  total  major  unit  quantity 
required  by  this  day 

Cumulative  %  of  total  major  unit  quantity 
delivered  by  this  day 


RPTTOTS  Edit  Limits 

Report  Total  Summary  Output 


Stores  the  daily  requirements  delivery  profile  summarized  by  Requirement  Class  to  the 
destination  from  the  model  results 


#  K?  Field  Name 
I _ l - 


Model  Datatype 


t Domain [ Lookup  ^  B | V  ^ Unit 


Meas  Description 


1  Y  Theater 

2  Y  Requirement  Class 


3  Y  Cargo  Measure 

4  Y  Delivery  Day 

5  Daily  Quantity  Required 

6  Daily  Quantity  Delivered 

7  Cumulative  Required 

8  Cumulative  Delivered 

9  Daily  %  Required 

10  Daily  %  Delivered 

11  Cumulative  %  Required 

12  Cumulative  %  Delivered 


dayqnreqsum 

dayqndelsum 

cumqnreqsum 

cumgndelsum 

dayreqpersum 

daydelpersum 

cumreqpersum 

cumdelpersum 


THEATER 
REQ CLASS 

RPTMEAS 

simendday 

Long>=0 

Long>=0 

Long>=0 

Long>=0 

% 

% 

% 

% 


day 

Q 

Q 

Q 

Q 

% 


Theater 

Aggregated  requirement  class  for 
calculating  summary  cargo  delivery  versus 
required  totals  for  reports 
Cargo  quantity  measure 
Delivery  day 

Incremental  quantity  required  on  this  day 
Incremental  quantity  delivered  on  this  day 
Cumulative  quantity  required  by  this  day 
Cumulative  quantity  delivered  by  this  day 
Incremental  %  of  total  major  unit  quantity 
required  on  this  day 

Incremental  %  of  total  major  unit  quantity 
delivered  on  this  day 

Cumulative  %  of  total  major  unit  quantity 
required  by  this  day 

Cumulative  %  of  total  major  unit  quantity 
delivered  by  this  day 


RPTVEH  Edit  Limits 

Report  Vehicle  Loads  Output 


Provides  vehicle  itineraries  with  detailed  cargo  loads 


i - - - — — i - 

#  K?  Field  Name  Model  Datatype 

( Domain | Lookup ( B | V  ^ Unit  Meas  ^ 

1 

Y  Vehicle  Number 

VEHICLE 

2 

Y  Trip  Number 

TRIP 

3 

Y  Stop  Number 

STOP 

4 

Y  Cargo  Number 

CARGO 

5 

Y  Compartment  Type 

CPTMEAS 

6 

Y  Compartment  Measure 

CPTMEAS 

7 

Vehicle  Type 

VEHFLEET 

8 

Vehicle  Identifier 

VEHFLEET 

9 

Vehicle  Fleet 

VEHFLEET 

10 

Is  Unload? 

Yesf lag 

11 

Cargo  Category 

CARGO CAT 

12 

Cargo  Type 

CARGTYPE 

13 

Cargo  Basic  Quantity 

reqqn 

Q 

14 

Cargo  Basic  Measure 

BASMEAS 

15 

Begin  Load  or  Unload  Day 

DayToHr 

day  (hr) 

16 

End  Load  or  Unload  Day 

DayToHr 

day  (hr) 

17 

Compartment  Capacity 

Long>=0 

mt,cbl,pax 

18 

Compartment  %  Load 

0,150 

% 

19 

Compartment  Load 

Long*/- 

C 

Description 


Aircraft  sequential  number 
Trip  number 

Unique  stop  number  for  this  port  or  node 

facility  visit 

Cargo  or  shipment  number 

Compartment  type  for  the  vehicle 

Compartment  capacity  unit  of  measure 

Vehicle  type 

Vehicle  identifier 

Vehicle  fleet 

"Yes"  flag  to  indicate  that  a  stop  is  for 

unloading,  otherwise  blank 

Cargo  category  which  describes  the  kind  of 

cargo  being  transported 

Cargo  type  for  this  cargo 

Cargo  quantity  in  the  basic  unit  of  measure 
for  its  cargo  class  (ston,  pax,  cbbl) 

Cargo  quantity  basic  measure  {ston,  pax, 
cbbl) 

Day  that  the  cargo  begins  loading  or 
unloading  at  the  stop 
Day  that  the  cargo  ends  loading  or 
unloading  at  the  stop 

Compartment  stowage  capacity  in  this  unit 
of  measure 

Percent  of  compartment  capacity  loaded  in 
the  compartment  measure 
Total  quantity  of  cargo  loaded  in  the 
compartment  expressed  in  the  compartment 
measure,  accounting  for  stow  factors 
(negative  for  offload  stops  for  report 
sorting) 


1  Y  Vehicle  Type 

2  Y  Day 

3  Transport  Mode 

4  Total  Vehicles 


vtranmode 

vtot 


VEHTYPE  Vehicle  type 

simendday  day  Day  of  simulation 

MODE  Transport  mode  for  this  vehicle  type 

Short >“0  Total  number  of  vehicles  allocated  for  this 

vehicle  type  (in  some  cases  the  vehicles 
used  may  exceed  this  if  simulation  delays 
cause  vehicles  to  extend  their  scheduled 
trips  beyond  the  originally  planned  return 
day) 
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RPTVEHDY  Edit  Limits  Provides  a  summary  of  vehicles  in  use  by  day 

Report  Vehicle  Daily  Output 


#  K?  Field  Name 


5  Total  Vehicles  Used 

6  Vehicles  In  Transit 

7  Vehicles  In  Port 

8  Vehicles  In  Queue 

9  Vehicles  In  Slack 


Model  Datatype 

t 


vused 

vtransit 
vport 
vqueue 
vs lack 


Domain [ Lookup  B\V ^ Unit  Meas  ^ Description 


Short >=0  Number  of  v< 


Short >=0 
Short >=0 
Short  >*=0 
Short >=0 


Number  of  vehicles  in  use,  i.e.  in  transit 
or  in  port  or  in  queue  (sum  of  the  next 
three  fields) 

Number  of  vehicles  in  transit  for  this 
vehicle  type 

Number  of  vehicles  loading  or  unloading  in 
port  for  this  vehicle  type 
Number  of  vehicles  in  facility  queues  for 
this  vehicle  type 

Number  of  vehicles  carrying  cargo  but  in 
waiting,  e.g.  for  more  cargo  to  be 
available  or  for  the  theater  earliest 
depart  day 


RPTVTYPE 

Edit  Limits 

Provides  a  summary  of  vehicle  type  utilization 

Report  Vehicle  Type 

Output 

#  K?  Field  Name 

i  < 

^ Model  Datatype 

Domain  I  Lookup 

i  i 

B | V  ^  Unit  Meas 

1  Y  Vehicle  Type 

VCPTTYPE 

2  Y  Compartment  Type 

VCPTTYPE 

3  Transport  Mode 

rptvehmode 

MODE 

4  Total  Vehicles 

rptvehtot 

Short >=0 

5  Total  Vehicles  Used 

rptvehused 

Short >=0 

6  Total  Days  Loaded 

rptvehtim 

Long>=0 

days 

7  Total  Travel  Miles 

rptvehdist 

Long>=0 

nmi 

8  Number  of  Trips 

rptvehtrips 

Long>=0 

9  Avge  Peak  %  Loaded 

rptvehpkld 

Long>=0 

% 

Vehicle  type 
Compartment  type 
Transport  mode 

Total  number  of  vehicles  available  for  this 
vehicle  type 

Number  of  vehicles  used  for  this  vehicle 
type 

Total  vehicle -days  of  travel  while  carrying 
cargo,  excluding  empty  legs 
Total  vehicle-miles  traveled  for  this 
vehicle  type  while  carrying  cargo, 
excluding  empty  legs 

Total  number  of  vehicle  trips  for  this 
vehicle  type 

Average  over  all  trips  of  the  vehicle 
compartment  peak  %  loaded  (in  each  trip, 
the  peak  is  over  the  trip  and  over  all 
measures  in  the  compartment,  including  the 
vehicle  payload  for  the  critical  leg) 


SERVICE 

Service 


#  K?  Field  Name 

i  i 


1  Y  Service 


Edit  Limits  Lists  the  U.S.  military  services 


Model  Datatype 


Domain | Lookup  B|v  Unit  Meas  Description 


STAGE 

Edit  Limits 

Stage  Location 

#  K?  Field  Name 


1  Y  Stage  Name 

2  Stage  Node 


A15  Name  of  the  military  service 


Edit  Limits  Lists  the  staging  deployments  which  have  predecessor  and  successor  requirements 


Model  Datatype  Domain | Lookup  B|V  Unit  Meas  Description 


stagenode 


Stage  Latest  Depart  Day  stagelatedep 


Stage  Earliest  Depart  Day  stageearlydep 
Delay  Hours  at  Node  reqdel 


stagedep 


A15 

NODE 

DayToHr 


DayToHr 
Hour sDe lay 

DayToHr 


day  (hr) 


day  (hr) 
hr 

day  (hr) 


Name  given  to  the  staging  deployment 
Node  or  port  at  which  staging  occurs 
Las test  depart  day  for  this  staging  after 
which  requirements  may  proceed 
independently  without  visiting  the  staging 
node 

Earliest  depart  day  for  this  staging 
Delay  hours  at  the  intermediated  node  for 
consolidation,  assembly,  etc. 

Estimated  target  departure  time  from  this 
staging  node 


STDSTOP 
Standard  Stop 


#  K?  Field  Name 

i  i 


1  Y  Planning  Fleet 

2  Y  Stop  Sequence 


Arrive  Day 

Node 
Facility 
Depart  Day 


Edit  Limits  Defines  the  stop  sequence  for  standard  prescheduled  routes  used  in  vehicle 

intialization;  the  stops  repeat  cyclically  if  the  first  node  and  facility  match  the  last 


Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 


PLANFLT 
Short >=1 


DayToHr 

FACILITY 

FACILITY 

DayToHr 


Standard  prescheduled  route  identifier 
Stop  sequence  number  for  this  prescheduled 
planning  fleet  (stops  are  assumed  to  repeat 
cyclically  if  the  first  and  last  stop  have 
the  same  node  and  facility) 

Yes  day  (hr)  Arrive  day  offset  for  this  prescheduled 
stop  sequence,  starting  from  zero  (the 
actual  stop  time  is  depends  on  the  offset 
in  VEHFLEET  and  the  number  of  iterations 

Yes  Node  associated  with  this  prescheduled  stop 

sequence  number 

Facility  associated  with  this  prescheduled 
stop  sequence  number 

Yes  day  (hr)  Depart  day  offset  for  this  prescheduled 
stop  sequence,  starting  from  zero 
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STOP 

Edit  Limits 

stop 

Output 

#  K?  Field  Name 

t _ _ 

1  Y  Stop  Number 

2  Arrive  Day 


3  Node 

4  Facility  Name 

5  Depart  Day 

6  Is  Unload? 


Model  Datatype 


stpfac 


stpdep 

isstpuld 


7  Hours  Wait  for  Facility  stpwaitfac 


^DomainlLookup^lV^nit  Meas 
Record#  BigSt 
DayToHr  Yes  day  (hr) 


FACILITY  Yes 

FACILITY 

DayToHr  Yes  day  (hr) 

Yesflag 

HoursDelay  hr 


8  Trip  Number 

9 


stptrip 

listcrg 

nextstop 

stpstatus 

stop_is_ammo 

stop_due 

stop_delay 


DayToHr 


Short +/- 


Description 

I - - - 

Unique  stop  number  for  this  port  or  node 
facility  visit 

Arrive  day  at  the  stop  port  if  a  facility 

is  available  (the  actual  arrive  day  can  be 

delayed  further  by  facility  constraints) 

Node  at  which  the  stop  is  made 

Port  or  node  facility  at  which  the  stop  is 

made,  if  node  is  an  airport  or  seaport 

Depart  day  from  the  stop  port 

Yes  if  a  stop  is  for  unloading,  otherwise 

blank 

Hours  vehicle  spent  waiting  for  port 
facilities  and  throughput  capacity  to 
arrive  or  depart 

Trip  number  associated  with  this  stop 
List  of  cargos  at  the  stop 
(>carglddy, >crgulddy) 

Next  stop  for  the  same  trip  in  arrive  day 
order 

Stop  status  set  to  STOPNOTARRIVED, 
STOPARRIVED,  or  STOPDEPARTED  depending  on 
whether  the  stop  has  not  yet  arrived,  has 
arrived,  or  has  departed  in  simulation 
True  if  the  stop  has  ammunition  cargo, 
otherwise  False 

Time  that  a  prescheduled  stop  is  due  when  a 
vehicle  has  a  Starting  Route,  set  to  the 
Last  Simulation  Day  for  other  stops 
Delay  to  a  stop  arrival  due  to  link 
congestion  on  the  route  used  to  arrive  at 
the  stop 


ST0P2 

Shadow  Stop 


#  K?  Field  Name 
l _ I - 

1  Y  Stop  Number 

2  Arrive  Day 

3  Node 

4  Facility  Name 

5  Depart  Day 

6  Is  Unload? 


7  Hours  Wait  for  Facility 

8  Trip  Number 


Edit  Limits  Provides  a  shadow  copy  of  the  STOP  table  for  form  and  report  linkages 
Output 


Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 


DayToHr 

FACILITY 

FACILITY 

DayToHr 

Yesflag 

HoursDelay 


day  (hr) 


day  (hr) 


Unique  stop  number  for  this  port  or  node 

facility  visit 

Arrive  day  at  the  stop  port 

Node  at  which  the  stop  is  made 

Port  or  node  facility  at  which  the  stop  is 

made,  if  node  is  an  airport  or  seaport 

Depart  day  from  the  stop  port 

"Yes"  flag  to  indicate  that  a  stop  is  for 

unloading,  otherwise  blank 

Hours  vehicle  spent  waiting  for  port 

facilities 

First  stop  arrive  day  of  the  trip 
associated  with  this  stop 


STOWFACT 

Edit 

Limits 

Stow  Factor 

Keys 

Comput 

#  K?  Field  Name 


1  Y  Compartment  Type 

2  Y  Compartment  Measure 

3  Y  Cargo  Type 

4  Stow  Factor  % 


STOWPEN 
Stow  Penalty 


#  K?  Field  Name 


Edit  Limits 
Keys  Comput 


Model  Datatype  ^Domain jLookup^BlV^ Unit  Meas  Description _ _ _ _ 


CPTMEAS  Compartment  type 

CPTMEAS  Compartment  stowage  measure 

CARGTYPE  Cargo  type  for  a  specific  transport  mode 

stowfact  StowFactor  Q/100C  or  Stow  efficiency  in  percent  for  loading  the 

cargo  type  in  the  compartment  type  for  this 
measure,  including  basic  quantity 
conversion  if  the  cargo  measures  don't 
match,  expressed  in  %  Q/C  (i.e.,  cargo 
quantity  stowed  per  100  compartment 
capacity  measure) 

qnoffset  MEASURE  Offset  for  this  cargo  type  (or  its  cargo 

category)  relative  to  its  first  measure  in 
order  to  match  this  compartment  measure 
(normally  ranges  from  0  to  NMEASURE-1;  an 
offset  of  NMEASURE  indicates  no  cargo 
measure  matches  the  compartment  measure) 
stowfactpen  STOWPEN  STOWPEN  record  matching  this  stow  factor 


Lists  combinations  of  compartment  types  and  cargo  types  along  with  stow  penalties 


1  Y  Compartment  Type 

2  Y  Cargo  Type 

3  Is  Stow  Excluded? 

4  Stow  Penalty 


Model  Datatype 

i  _  _ _ _ _ 


stowcpttyp 

stowcrgtyp 

isnostow 

stowpen 


Domain | Lookup  B|V  Unit  Meas  Description 


CPTTYPE 

CARGTYPE 

Yesflag 


Vehicle  compartment  type 

Cargo  type  with  matching  transport  mode 

Yes  if  this  cargo  type  is  excluded  from 

stowage  in  this  compartment  type 

Stow  penalty  per  unit  basic  quantity  of 

cargo  for  loading  into  this  vehicle 
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STOWPEN 

Edit 

Limits 

Lists  combinations  of  compartment  types  and  cargo  types  along  with  stow  penalties 

Stow  Penalty 

Keys 

Comput 

*  K?  Field  Name 


Model  Datatype 


nextstowpen 


STOWPEN 


compartment 

Next  stow  penalty  record  for  this  cargo 
type  sorted  in  order  of  increasing  stow 
penalty  _ 


SUPPCONS 

Supply  Consumption 


Edit  Limits 


Specifies  standard  daily  consumption  rates  of  resupply  for  consuming  requirements 


#  K?  Field  Name 


Model  Datatype 


Domain | Lookup ( B | V | Unit  Meas  description 


L_ 


1  Y  Consuming  Req  Type 

2  Y  Consumption  Theater 


6  Accompany  Days  of  Supply  supaccomp 


REQTYPE 

supcons_theater 

THEATER 

supconscat 

CARGOCAT 

supcatcons 

CARGOCAT 

supdemrate 

0,999 

supaccomp 

Byte>=0 

Requirement  type  that  consumes  resupply  in 
the  theater 

Destination  theater  in  which  consumption 
occurs 

Consuming  cargo  category  for  estimating 
consumption 

Supply  cargo  category  that  is  stored  at  an 
inventory  site 

Q/  (1000Q) /  Daily  consumption  rate  expressed  as  supply 
basic  quantity  per  thousand  basic  quantity 
of  the  consuming  category  after  arrival  at 
its  destination  in  the  theater 
Q/ (1000Q)  Accompanying  supply  quantity  in  days  of 

supply  for  this  consuming  requirement  type 


SUPPREQ  Edit  Limits 

Supply  Requirements 


Lists  the  information  needed  to  generate  static  and  dynamic  resupply  requirements 


#  K?  Field  Name 


Model  Datatype 


Domain  I  Lookup  B|V  Unit  Meas  Description 
j _ ! _  i  .i - i - 


L. 


1 

Y  Supply  Requirement  ID 

A15 

2 

Supply  Source  Node 

NODE 

Yes 

3 

Supply  Category 

SUPSTORE 

Yes 

4 

Supply  Storage  Node 

SUPSTORE 

Yes 

5 

Supply  Major  Unit 

MAJUNIT 

Yes 

6 

Supply  Availability  Date 

DayToHr 

Yes  day 

(hr) 

7 

Supply  Delivery  Time 

DayToHr 

Yes  day 

(hr) 

8 

Priority  Order 

1,99 

Supply  requirement  identifier  for  static 
and  dynamic  resupply  generation 
Resupply  origin  node 
Resupply  cargo  category 

Resupply  storage  node  or  terminal  storage 
location 

Resupply  major  unit,  which  has  a 
requirement  type  that  is  resupply 
Earliest  time  that  resupply  can  be  orderd 
from  this  requirement 

Notional  resupply  delivery  time  or  lead 
time,  usually  initially  for  generating 
static  orders  and  recomputed  for  dynamic 
resupply 

Scheduling  priority  order  when  generation 
movement  requirements  for  resupply 


SUPQUAN 

Supply  Quantities 

Edit 

Limits 

Lists  the  units  of  measure  and  relative  quantities  as  density  information  for  generating 
resupply  movements 

#  K?  Field  Name 

Mode 

i 

»1  Datatype  Domain | Lookup  t  B | V  ^  Unit  Meas 

Description 

i - 1 - — - 

1  Y  Supply  Requirement  ID 

2  Y  Unit  of  Measure 

3  Quantity 

SUPPREQ 

MEASURE 

Long>=0  Yes  Q 

Supply  requirement  identifier  matching  a 
record  in  SUPPREQ 

Unit  of  measure  for  the  resupply  category 
Relative  quantity  of  resupply  in  the  unit 
of  measure,  used  to  scale  order  quantites 
with  consistent  density  ratios 

SUPSTORE 

Supply  Destination 

Edit 

Limits 

Provides  data  about  resupply  storage  terminals  in  the  theater 

#  K?  Field  Name 

1 _ 1 - 

Model  Datatype  Domain | Lookup  B|V  Unit  Meas 

i _  - _ 1 _ ! _ 1 _ 1 - 

Description 

J _ _ _ 

3 

4 

5 

6 
8 
9 

10 


Supply  Cargo  Category 

CARGOCAT 

Supply  Storage  Node 

supstorage_node 

NODE 

Prepositioned  Stock 

supstorestock 

reqqn 

Q 

Stock  Safety  Level 

supreorder 

reqqn 

Q 

Stock  Order  To  Level 

suporderto 

reqqn 

Q 

Min  Order  Quantity 

supminorder 

Long>-l 

Yes  Q 

supleadtim 

DayToHr 

day 

sup_demand 

Long>=0 

sup_onhand 

Long+/ - 

Q 
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(hr) 


inventory  site 

Resupply  storage  node  or  terminal  storage 
location 

Quantity  of  reserved  stock  prepositioned  at 
this  supply  storage  node 

Minimum  safe  stockpile  level,  which  is  used 
to  reordered  supply  when  the  inventory 
level  is  projected  to  fall  below  this  level 
at  the  current  estimated  lead  time  and 
consumption  rate 

Target  stockpile  level  to  reorder  to  when 
orders  are  placed 

Minimum  order  quantity  for  this  supply 
category  in  this  theater 
Estimated  supply  lead  time  based  on  the 
best  supplier 

Demand  for  estimating  inventory  position  in 
reorder  calculations 
Amount  of  inventory  on  hand,  can  be 
negative  for  back  order  warnings 


Directory  Type :  Scenario 


SUPSTORE 

Supply  Destination 

Edit 

Limits 

Provides  data 

about  resupply  storage  terminals  in  the  theater 

*  K?( Field  Name 

Mode 

il  Datatype 

Domain | Lookup  B|V^Unit  Meas 

Description 

- - 

11 

12 

sup_int r ans i t 
listsupstorecargo 

Long>=0 

CARGO 

Total  basic  quantity  in  transit 

List  of  representative  cargos  for  this 
suppstore 

THEATER 

Theater 

Edit 

Limits 

Provides  data 

about  the  theaters 

#  K?  Field  Name 

1 _ 1 - 

Mode 

_ 1 _ 

il  Datatype 

( Domain | Lookup ( B | V ( Unit  Meas 

Description 

Theater 

Mobilization  M  Day 

A15 

DayToHr 

day 

Deployment  C  Day 

DayToHr 

day 

Combat  D  Day 

DayToHr 

day 

Earliest  Depart  Day 

earlydep 

DayToHr 

day 

Start  Planning  Day 

thtrbegplan 

DayToHr 

day 

listexthtr 

EXCLUDE 

Theater  name 
Theater  M  day  or  begin  mobilization  day 
relative  to  global  day  0 
Theater  C  day  or  commence  deployment  day 
relative  to  global  day  0 
Theater  D  day  on  which  casualties  and 
attrition  begin,  relative  to  global  day  0 
(hr)  Earliest  day  that  a  vehicle  can  leave  after 
exiting  the  POE  facility  before  traveling 
towards  this  theater  (cargo  can  be 
preloaded  and  the  facility  exited) 

(hr)  Day  on  which  requirements  can  first  start 
being  considered  for  scheduling  to  this 
theater 

List  of  exclusions  for  this  theater,  if  any 


THTRREQ  Edit  Limits 

Theater  Require  Type  Keys  Full 

Provides  data  about  passenger  weights  by  theater  and  requirement  type 

#  K?  Field  Name  Mode 

i _ 1 - - 1 - 

si  Datatype  Domain | Lookup  BlV^Unit  Meas  ^ Descript ion 

1  Y  Theater 

2  Y  Requirement  Type 

3  Pax  Weight 

thtrpaxwt 

THEATER 

REQTYPE 

1,999 

Yes  lbs /Pax 

4  Accompanying  Gear 

thtracmpywt 

Short >=0 

lbs /Pax 

5 

thtreq_total 

Long>=0 

basic  unit 

6 

thtreq_delivered 

Long>=0 

basic  unit 

7 

thtreq_estimated 

Long>=0 

basic  unit 

Theater  name 

Requirement  or  unit  type 

Weight  in  pounds  of  each  passenger  and  his 
carry-on  gear  for  vehicle  pay load/ weight 
calculations  (does  not  affect  facility 
throughput ) 

Weight  in  pounds  of  non-carry-on 
accompanying  gear  per  passenger  for  both 
facility  throughput  and  vehicle  payload 
calculations 

Total  quantity  required  for  this  theater 
and  requirement  type,  accumulated  as  of  the 
current  simulation  time  plus  planning 
horizon 

Cumulative  delivered  for  this  theater  and 
requirement  type,  as  of  the  current 
simulation  time 

Cumulative  estimaged  quantity  of  scheduled 
cargo  for  this  theater  and  requirement 
type,  forecasted  into  the  future  as  of  the 
Planning  Horizon 


TIMEVARY 
Time  Variation 


Edit  Limits 


Specifies  data  which  changes  over  time  (derived  from  user  inputs  in  the  associated  data 
tables,  should  not  be  edited  directly) 


Field  Name 

Model  Datatype 

i 

Domain | Lookup  ^ 

1 B  |  V| 

Change  Day 

tvtim 

0,999 

Table  to  Vary 

VARYPARD 

Field  to  Vary 

VARYPARD 

Key  Field  Values 

A100 

New  Value 

twalue 

Long+/- 

Yes 

Computed  Model  Datatype 

tvdattyp 

A20MODDAT 

1  Ye 

Computed  Record  Number 

tvrecnum 

Short >=0 

1  Ye 

day  Day  on  which  change  occurs  (not  DayToHr 

domain,  leave  as  days) 

Table  name  which  has  a  datatype  that 
changes  over  time 

Nonkey  descriptive  datatype  which  changes 
over  time 

Key  field  value (s)  stored  as  a  single  text 
string  using  •  as  a  field  delimiter 
varies  New  numeric  value  of  the  datatype  which 
takes  effect  on  the  change  day  (for  Yes 
flag  fields,  the  new  value  is  stored  as  1 
for  Yes,  otherwise  blank  or  0) 

Computed  model  datatype  name  for  the 
changed  data 

Computed  record  number  of  the  changed 
record 


TRIP 

Trip 

Edit  Limits 
Output 

Lists  the  trips 

(voyages,  flights,  etc.)  and  the  assigned  vehicles 

#  K?  Field  Name 
l _ 1 - 

( Model  Datatype 

Domain | Lookup  ^ B | V ^ Unit  Meas  ^ Description 

1  Y  Trip  Number 

2  Vehicle 

3  Convoy  Trip  Number 


tripvehicle 

tripcnvy 


Record#  BigSt 

VEHICLE 

CONVTRIP 


Trip  number 

Vehicle  assigned  to  this  trip 
Convoy  trip  number  this  voyage  is  assigned 
to,  if  any  (if  a  trip  has  multiple  convoys 
between  different  stops,  only  the  last 
convoy  trip  is  stored  here) 
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TRIP 

Trip 

Edit  Limits 
Output 

Lists  the  trips 

(voyages,  flights,  etc.)  and  the  assigned  vehicles 

#  K? ( Field  Name 

Mode 

i 

il  Datatype 

Domain  1  Lookup  B|V  Unit  Meas  Description 

1 _ ! _  1  l - 1 - - - - — 

4 

Number  of  Vehicle  Trips  tripnumveh 

Long>=0 

5 

next trip 

TRIP 

6 

liststop 

STOP 

7 

curstp 

STOP 

8 

curcrg 

CARGO 

10 

11 


12 


13 

14 


curedep 

curqn 

curtriptime 

heaptrip 


curfac 

nextcnvytrip 


DayToHr 


Long>=0 

Long>=0 


TRIP 


FACILITY 


TRIP 


trip 

Next  trip  (voyage,  flight,  etc.)  for  the 
same  vehicle 

List  of  stops  in  this  trip  sorted  by  arrive 
day 

Current  simulate  stop  of  the  trip,  either 
in  process  or  most  recently  completed  (0  if 
the  trip  has  not  yet  begun  simulation  at 
all) 

Current  cargo  ready  for  loading/unloading 
at  the  current  simulation  stop  of  the  trip 
(0  if  all  cargos  at  the  curstop  are 
completed  but  the  next  stop  cannot  be 
started  yet  because  the  vehicle  is  exiting 
or  in  transit) 

day  (hr)  Current  largest  early  depart  time  over  all 
cargos  at  the  stop  currently  being 
simulated  (used  for  special  missions  or 
theater  earliest  depart  and  may  delay  the 
ship  departure  after  all  cargo  is  loaded 
and  the  facility  is  departed) 

Q  Current  quantity  remaining  for  loading  or 

unloading  the  current  cargo 

day  (hr*10  Arrive  time  for  simulation  of  the  current 

or  next  stop  of  this  trip,  used  for  sorting 
the  trip  heap;  now  multiplied  by  10000  and 
added  to  original  stop  arrive  time  to 
maintain  original  schedule  order 
Priority  queue  of  trips  heap -sorted  in 
order  of  the  arrive  day  of  the  trip  current 
simulation  stop  (the  end  of  the  heap  is 
also  used  to  store  unfinished  trips 
simulated  on  the  current  day  prior  to 
putting  them  back  on  the  heap) 

Current  facility  for  the  current  simulation 
stop 

Next  trip  in  the  current  convoy  buildup 
being  prepared  for  scheduling 


VARYPAR 

Vary  Parameter 

Edit  Limits 
Display  Onl 

Specifies  data 

elements  to  be  varied  parametrically 

#  K?  Field  Name 

1 _ 1 _ 

( Model  Datatype 

( Domain | Lookup ( B | V  ^  Unit  Meas  description 

1 

Y  Table  to  Vary 

VARYPARD 

2 

Y  Field  to  Vary 

VARYPARD 

3 

Y  Key  Field  Values 

A100 

4 

Start  Value 

vpstartval 

Long>=0 

5 

Increment 

vpinc 

Short >=1 

6 

Number  of  runs 

vpnumruns 

1,99 

7 

Computed  Model  Datatype 

vpdattyp 

A2 OMODDAT 

8 

Computed  Record  Number 

vprecnum 

Short >=0 

Table  with  parameter  to  vary 
Parameter  to  vary 

Key  field  value (s)  stored  as  a  single  text 
string  using  •  as  a  field  delimiter 
Yes  Starting  value  for  the  parameter  variation 

(Yes /blank  values  input  as  1/0) 

Yes  Incremental  value  for  the  parameter 

variation 

Yes  Number  of  runs  for  the  parameter  variation 

|  Ye  Computed  model  datatype  name  for  data  to  be 

varied  parametrically 

|  Ye  Computed  record  number  to  be  varied 

parametrically 


VARYRUN 

Edit  Limits 

Stores  saved  values  from  a  sensitivity  run 

Vary  Output  Run 

Output 

#  K? | Field  Name _ 

1  Y  Run 

2  Y  Table 

3  Y  Field 

4  Y  Key  Field  Values 

5  Field  Value 


Model  Datatype 

runnum 

runsave 


runval 


Domain | Lookup ^ B | V ^ Unit  Meas 

Record#  VehCp 
VARYSAVE 
VARYSAVE 
VARYSAVE 

Long>=0 


Description 

Sequential  run  number 
Table  with  the  nominal  value 
Name  of  the  parameter 

Key  field  value (s)  stored  as  a  single  text 
string  using  *  as  a  field  delimiter 
Value  of  the  saved  parameter 


VARYSAVE 

Edit  Limits 

Defines  data  to  be  saved  across  multiple  runs  when  data  elements  have  parameter 

Vary  Save  Data 

variations  or  sampling  distributions 

#  K?  Field  Name  Model  Datatype  Domain | Lookup  B|V  Unit  Meas  Description 

1 _ i  _ I _ _ _ 1 _ _ _ 1 _ l _ 1 - 


1  Y  Table  to  Save 

2  Y  Field  to  Save 

3  Y  Key  Field  Values 

4  Computed  Model  Datatype  savedattyp 

5  Computed  Record  Number  saverec 


VARYSTAT 

VARYSTAT 

A100 

A2  OMODDAT 


|  Ye 
|  Ye 


Table  name  which  has  data  to  be  saved  over 

multiple  sensitivity  runs 

Nonkey  data  element  which  is  to  be  saved 

over  multiple  sensitivity  runs 

Key  field  value (s)  stored  as  a  single  text 

string  using  *  as  a  field  delimiter 

Computed  model  datatype  number  for  sampled 

data 

Computed  record  number  of  the  sampled  data 


Short>=0 


Directory  Type :  Scenario 


VARYSTAT  Edit  L 

Vary  Sampled  Data 

K?  Field  Name 

1 - 

1  Y  Table  to  Sample 

2  Y  Field  to  Sample 

3  Distribution  Type 

4  Distribution  Parameter 

5  Number  of  Runs 


Edit  Limits  Lists  tables  and  data  elements  which  are  sampled  from  a  stochastic  distribution  taking 
as  mean  the  database  value 


Model  Datatype 


vsdistyp 

vdistpar 


^ Domain | Lookup | Vt Unit  Meas  Description 
VARYPARD  Table  name  i 


VARYPARD 

VARYDIST 

Long>=0 


1,100 

A20MODDAT 


Computed  Model  Datatype  vstatdattyp  A20MODDAT  |Ye  Computed  i 

data 


VCPTTYPE  Edit  Limits  Lists  the  compartments  available  for  each  vehicle  type 

Veh  Cpt  Type  _ _ 


#  K?  Field  Name  Model  Datatype  Domain | Lookup  B|V  Unit  Meas  Descriptl 


Table  name  which  has  a  datatype  sampled 
from  a  stochastic  or  parametric 
distribution 

Nonkey  descriptive  datatype  which  has  a 
sampling  distribution 

Yes  varies  Sampling  distribution  type  for  the  data 
(positive  values  only) 

Distribution  parameter  which  defines  the 
sampling  distribution  together  with  the 
mean  or  median  as  derived  from  the  database 
value 

Yes  Number  of  runs  for  this  stochastic  datatype 

|  Ye  Computed  model  datatype  name  for  sampled 

data 


1  Y  Vehicle  Type 

2  Y  Compartment  Type 


Domain | Lookup | V  Unit  Meas  ^ Description 


VEHTYPE  Vehicle  Type  (e.g.  C-5  for  air;  Breakbulk 

for  sea;  Van,  Flatbed,  Special, 
Refrigerated,  etc.  for  motor;  Flatcar  for 
Rail) 

cpttyp  CPTTYPE  Name  of  an  available  compartment  type  for 

the  vehicle  type 

Edit  Limits  Defines  load  capacities  for  each  vehicle  identifier,  compartment,  and  unit  of  measure 
Keys  Comput  _ 


VEHCAP 

Vehicle  Capacity 


#  K?  Field  Name 


1  Y  Vehicle  Type 

2  Y  Vehicle  Identifier 

3  Y  Compartment  Type 

4  Y  Compartment  Measure 

5  Capacity 


Model  Datatype 


vcptcap 

vcpttype 


Domain | Lookup  B|V  Unit  Meas  Description 


VEHDATA  Vehicle  type 

VEHDATA  Vehicle  identifier  for  this  vehicle  data 

CPTMEAS  Compartment  type  for  this  vehicle  type 

CPTMEAS  Compartment  stowage  measure 

VehCap  Yes  mt,cbl,pax  Stowage  capacity  allowed  for  this  vehicle 

compartment  and  measure 

VCPTTYPE  Vehicle  and  compartment  type  matching  this 

capacity  record 


VEHDATA 

Edit  Limits 

Vehicle  Data 

Edit  Limits  I  Provides  detailed  characteristics  about  each  kind  of  vehicle  identified  in  the  system 


#  K?  Field  Name 


1  Y  Vehicle  Type 

2  Y  Vehicle  Identifier 

3  Cruising  Speed 


Model  Datatype 


vtype 

vspeed 

vmaxld 


Max  Cargo  Load  vmaxld 

Facility  Length  Required  vfaclen 
Facility  Width  Required  vfacwid 

Facility  Dimension  Req.  vfacdim 

Facility  Rating  Required  vf aerating 

f irstvehcap 
firstvehfleet 


Domain  I  Lookup  BjV  Unit  Meas  Description 
i _ _ . _ i _ ! _ i _ i - 


VEHTYPE  Vehicle  type  name 

A25  Vehicle  identifier  for  this  vehicle  data 

1,999  Yes  nmi/hr  Cruising  speed  of  this  vehicle,  in  nautical 

mph 

VehMaxLd  Yes  ston  Maximum  allowed  cargo  load  over  all 

compartments  for  this  vehicle,  in  ston 

Short >=0  ft  Facility  length  required  for  loading  and 

unloading 

0,999  ft  Facility  width  required  for  loading  and 

unloading 

0,999  varies  Facility  dimension  required  (e.g.,  draft 

for  sea)  for  loading  and  unloading 

Short>=0  varies  User-definable  facility  rating  required  for 

loading  and  unloading  (e.g.,  landing 
classification  number  for  air,  boom 
capacity  for  sea) 

VEHCAP  First  vehicle  compartment  capacity  for  this 

vehicle  identifier 

VEHFLEET  First  vehicle  availability  record  for  this 

vehicle  identifier 


VEHFLEET 
Vehicle  Fleet 


#  K?  Field  Name 


Edit  Limits  Lists  the  availability  of  vehicles  by  starting  location  or  route,  starting  time  for 
scheduling,  and  number  of  vehicles 


1  Y  Vehicle  Type 

2  Y  Vehicle  Identifier 

3  Y  Vehicle  Fleet 

4  Number  of  Vehicles 

5  Start  Scheduling  Day 

6  Stop  Scheduling  Day 


Model  Datatype 


vehdata 

fit 

numveh 

start_schedule 

fltret 


Domain  I  Lookup  B|V  Unit  Meas  Description 


VEHDATA 

VEHDATA 

FLEET 
Short  >«=0 

DayToHr 

DayToHr 


Vehicle  type 

Vehicle  identifier  for  this  starting 
location 

Fleet  identifier  for  this  starting  location 
Number  of  vehicles  in  the  fleet  for  this 
vehicle  type 

day  (hr)  Administrative  day  that  this  fleet  and 
vehicle  type  are  first  available  for 
scheduling  new  trips,  stops,  and  cargo 
day  (hr)  Stop  day  after  which  this  fleet  and  vehicle 
type  are  returned  to  its  starting  node  or 
route  with  no  more  use  (blank  or  0  is 
treated  as  available  through  the  simulation 
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Directory  Type:  Scenario 


VEHFLEET  Edit  Limits  Lists  the  availability  of  vehicles  by  starting  location  or  route, 

Vehicle  Fleet  scheduling,  and  number  of  vehicles 


starting  time  for 


1 _ 

#  K? 

Field  Name 

Model  Datatype 

i 

Domain | Lookup ^  B  |  V  ^  Unit  Meas  ^ 

7 

Start  Node 

startfac 

FACILITY 

8 

Start  Facility 

FACILITY 

9 

Start  Route  Offset 

-99,999 

day 

10 

Start  Route  Last  Day 

last_presched_day 

DayToHr 

day 

11 

Special  Mission 

f ltmiss 

MISSION 

12 

New  Vehicle  Penalty 

newvehpen 

Short>=0 

$/new  veh 

13 

Call  Sign 

A15 

14 

Other  Identifier 

A15 

15 

Requirement 

vehfleet_require 

REQUIRE 

16 

firstvehicle 

VEHICLE 

17 

fltlaststp 

STOP 

18 

fltusetime 

HoursDelay 

19 

cndpoefac 

FACILITY 

20 

cndpodfac 

FACILITY 

21 

cndcritleg 

Short>=0 

22 

nextreqvflt 

VEHFLEET 

23 

start day 

DayToHr 

day 

24 

vehf lee  t_load 

Long>=0 

basic  meas 

25 

load_is_current 

Boolean 

Description 


end  date) 

Starting  home  base  node  for  this  fleet  and 
vehicle  type  (a  vehicle  starts  at  and 
returns  to  its  home  base  if  not  otherwise 
assigned) 

Starting  home  base  facility  for  this  fleet 
and  vehicle  type  (a  vehicle  starts  at  and 
returns  to  its  home  base  if  not  otherwise 
assigned) 

Offset  day  for  this  fleet  and  vehicle  for  a 
standard  prescheduled  starting  route  cycle 
Last  day  beyond  which  the  prescheduled 
starting  route  is  no  longer  cycled 
Special  mission  which  restricts  this  fleet 
to  matching  special  mission  movement 
requirements  for  a  designated  period  of 
time 

Penalty  for  the  first  use  of  a  new  vehicle 
of  this  type  and  fleet 

International  call  sign  or  identifier  of 
the  vehicle  and  fleet 
Other  identifier  such  as  NXSC  {Naval 
Intelligence  Security  Code)  for  the  vehicle 
and  fleet 

Requirement  by  which  this  vehicle  fleet  is 
delivered  (these  vehicles  are  not  available 
until  the  requirement  is  completely 
delivered) 

Lookup  into  the  vehicle  table 

Fleet  last  stop  for  the  current  day  for  the 

aggregated  vehicle  flow  scheduling 

algorithm 

Fleet  usage  time  in  the  Vehicle  Flow 
scheduling  algorithm 

Candidate  POE  facility  for  this  vehicle 
fleet  assignment 

Candidate  POD  facility  for  this  vehicle 
fleet  assignment 

Critical  leg  from  POE  to  POD  for  this 
vehicle  fleet  candidate  assignment 
Next  pointer  to  list  of  lift  assets 
delivered  with  a  requirement 
Physical  start  day  that  this  vehicle  and 
fleet  can  first  appear  in  the  plan 
Quantity  carried  by  a  vehicle  fleet  in  mode 
planning 

Flag  that  the  vehfleet  load  value  is 
current 


VEHICLE 

Edit  Limits 

Tracks  status 

and  location  of  each  unique  vehicle 

Vehicle 

Output 

#  K?  Field  Name 

1 _ l - 

Model  Datatype 

i 

( Domain | Lookup  t  B | V ( Unit  Meas  ^ Description 

1 

Y  Vehicle  Number 

Record#  Vehic 

2 

Vehicle  Type 

vehf It 

VEHFLEET 

Yes 

3 

Vehicle  Identifier 

VEHFLEET 

4 

Vehicle  Fleet 

VEHFLEET 

5 

Attrit  or  Damage  Day 

vehattr 

DayToHr 

day  (hr) 

6 

Replace  or  Repair  Day 

vehrep 

DayToHr 

day  (hr) 

7 

Computed  Course 

vcourse 

Degree 

Deg 

8 

Computed  Latitude 

vlat 

Lat 

deg  min 

9 

Computed  Longitude 

vlon 

Lon 

deg  min 

10 

listtrip 

TRIP 

11 

insbegstp 

STOP 

Vehicle  unique  sequential  number 

Vehicle  type 

Vehicle  identifier 

Vehicle  fleet  for  this  vehicle 

Last  attrit  or  breakdown  day  for  this 

vehicle ,  if  any 

Last  replacement  or  repair  day  for  this 
vehcile,  if  any 

Current  course  direction  computed  for  the 
current  date  and  time 

Current  latitude  computed  for  the  current 
date  and  time 

Current  longitude  computed  for  the  current 
date  and  time 

List  of  trips  for  this  vehicle 
Earliest  insertion  stop  at  the  end  of  a 
trip  after  which  cargo  insertion  into  a 
vehicle  route  can  begin 


VEHTYPE 

Edit  Limits 

Lists  vehicle  types  by  transport  mode 

Vehicle  Type 

#  K?  Field  Name 

I  | 

Model  Datatype 

^  Domain | Lookup ( B | V  ^ Unit  Meas 

Description 

1  Y  Vehicle  Type 

2  Route  Type 

3  Arrive/Depart  Time 

vrouttype 

varrdeptim 

A15 

ROUTTYPE 

Hour 

Yes 

hr 

Vehicle  type  name,  e.g.  Breakbulk  for 
sealift,  C-17  for  airlift,  etc. 

Route  type  to  use  for  this  vehicle  type 
Combined  total  additional  time  for  node 
arrival  and  departure  for  this  vehicle 
type,  such  as  takeoff/ landing  time  or  port 
maneuver  time  (adds  to  travel  time  and 
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VEHTYPE 

Edit  Limits 

Vehicle  Type 

Lists  vehicle  types  by  transport  mode 


K?  Field  Name 


4  Vehicle  Standard  Size  %  vehsizepc 


5  Time  Penalty 


6  Greedy  Vehicle  Level  vokcbr 


9  Attrit  Partial  Damage  %  vattrpart 


10  Repair  Days 


11  Replace  Days 


VFACDIM  Edit 

Veh  Fac  Dimen  Limit 


#  K?  Field  Name 

I  I 


1  Y  Vehicle  Type 

2  Y  Facility  Type 

3  Y  Max  Dimension  Measure 

4  Max  Cargo  Dimension 


reduces  the  average  block  speed,  but  does 
occur  not  affect  facility  parking) 

Size  %  vehsizepc  0,9999  Yes  %  Size  of  vehicle  relative  to  "standard" 

vehicle  size,  may  exceed  100%  for  larger 
vehicles,  used  for  allocating  facility 
berths  or  parking  spaces  (MOG) 

vtimpen  0,999  Yes  $/hr  Penalty  for  vehicle  usage  per  hour,  used  to 

compare  with  cargo  lateness  in  the 
scheduling  algorithm 

avel  vokcbr  Short >®0  Yes  $/$  Limit  on  the  acceptable  cost/benefit  ratio 

for  a  greedy  vehicle  trying  to  get 
additional  cargo  immediately  after  an 
assignment 

iplier  %  vlinkattrmult  %  %  Attrition  adjustment  multiplier  applied  to 

the  link  attrition  or  breakdown  rate  for 
this  vehicle  type  while  in  transit  (blank 
or  0  is  treated  as  100%) 

iplier  %  vnodeattrmult  %  %  Attrition  adjustment  multiplier  applied  to 

the  node  attrition  or  breakdown  rate  for 
this  vehicle  type  while  at  the  node  (blank 
or  0  is  treated  as  100%) 

amage  %  vattrpart  %  %  Percent  of  attritted  or  broken  down 

vehicles  which  are  partially  damaged  and 
can  be  repaired 

vrepair  DaysDelayToHr  day  (hr)  Delay  days  for  repair  of  a  partially 

damaged  vehicle,  after  which  the  vehicle 
continues  its  scheduled  itinerary 

vreplace  DaysDelayToHr  day  (hr)  Nonzero  vehicle  replacement  time  at  the 

initial  ALD  node  after  total  attrition  (if 
blank,  no  replacement  occurs) 

firstvcpttyp  VCPTTYPE  First  vehicle  compartment  type  for  this 

vehicle  type 

f irstvfactyp  VFACTYPE  First  facility  type  for  this  vehicle  type 

listexvehtyp  EXCLUDE  List  of  exclusions  for  this  vehicle  type, 

if  any 

firstvehdata  VEHDATA  First  vehicle  data  record  matching  this 

vehicle  type,  if  any 

nextvehtype  VEHTYPE  Next  vehicle  type  for  the  same  mode 

vmode  MODE  Transport  mode  of  this  vehicle  type 


Edit  Limits  Sets  cargo  dimension  limits  for  loading  onto  vehicle  types  at  facility  types 


Model  Datatype 


Domain J Lookup  B|V  Unit  Meas  Description 


vfacmaxdim 


Long>=0 


ft, ston 


Vehicle  type  with  cargo  dimension 
constraint 

Matching  facility  type  with  cargo  dimension 
constraint 

Cargo  dimension  constraint  measure  (Item 
Height  Ft,  Item  Weight  Ston,  etc.) 

Cargo  dimension  limit  to  exclude  cargo  that 
is  too  big  from  loading  on  this  vehicle 
type  at  this  facility  type 


VFACTYPE 

Edit 

Limits 

Veh  Facility  Type 

Keys 

Comput 

Lists  matchings  of  vehicle  types  and  facility  types  for  loading/unloading  cargo 


#  K?  Field  Name 

■  i 


1  Y  Vehicle  Type 

2  Y  Facility  Type 

3  Is  Vehicle  Excluded? 


4  Setup  Delay 


5  Shutdown  Delay 


Model  Datatype 


vfactyp 

isvfacexcl 


vfacsetupdel 


vfacshutdndel 


Domain  I  Lookup  BjV  Unit  Meas  Description 
i  1 _ i _ _ i _ i _ 


VEHTYPE 

FACTYPE 

Yesflag 


HoursDelay 


Hour sDe lay 


6  Facility  Visit  Penalty  vfacpen 


$/visit 


firstloadrate 


Vehicle  type 

Facility  type  with  matching  mode 
Yes  if  the  vehicle  type  is  excluded  from 
loading  and  unloading  cargo  at  this 
facility  type,  blank  otherwise  (vehicle  may 
still  refuel  unless  prevented  by  Is  Refuel 
Excluded?  field) 

Fixed  setup  or  entrance  delay  time  for  this 
vehicle  type  while  occupying  this  facility 
type  (the  vehicle  takes  parking  space  and 
the  facility  must  be  open  during  setup; 
setup  delays  vehicle  and  cargo 
loading /unloading) 

Fixed  shutdown  or  exit  time  for  this 
vehicle  type  while  occupying  this  facility 
type  (the  vehicle  takes  parking  space  and 
the  facility  must  be  open  during  shutdown ; 
shutdown  delays  vehicle  but  not  cargo 
loading  or  unloading) 

Penalty  for  multi- facility  visits  on  a 
single  trip,  used  in  the  scheduling 
algorithm  (the  first  POE  and  POD  facilities 
on  a  new  trip  are  not  penalized) 

First  load  rate  for  this  vehicle  type  and 
facility  type 
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8 


firstvfacdim  VFACDIM 


First  vehicle  type/ facility  type  dimension 
limit  in  VFACDIM 


Directory  Type :  System 


DIRLIST 

Directory  Listing 

Edit  Limits 
Update 

Lists  the 

available  user  databases  in  the  system 

#  K?( Field  Name 

Mode 

si  Datatype 

Domain | Lookup  ^ B | V  ^ Unit  Meas 

Description 

1  Y  Directory  Type 

2  Y  Subdirectory 

3  Classification 

4  Remarks 

D1RTYPE 

A8 

CLASSIF 

A255 

The  name  of  the  directory  type 

An  existing  8 -character  subdirectory  name 
for  this  directory  type  (multiple 
subdirectories  may  exist  some  directory 
types,  but  all  lookups  must  refer  only  to 
the  same  subdirectory  or  to  the  Refer 
subdirectory) 

Classification  if  any  for  this  directory 
Remark  or  comment  for  this  directory 

MAPDIR 

Map  Data  Directories 

Edit  Limits 
Hide 

Lists  the 

valid 

mapping  directories  computed  by  the  system 

#  K?  Field  Name 

( Mode 

>1  Datatype 

Domain | Lookup  ^  B | V  ^ Unit  Meas 

Description 

-L-. - - - 

1  Y  Name 

2  Path 

3  Comments 

A25 

A255  Yes 

A255 

Name  of  a  database  directory  (could  be: 
"dirlist ->subdir+ (dirtype) "  ) 

The  full  path  of  the  directory  where  the 
mapping  files  reside 

Additional  information  about  this  directory 
(from  dirlist  comments) 

PCEXPORT 

PC  Export  Table 

Edit  Limits 
Display  Onl 

Lists  the  table  being  exported  in  PC  Export  and  provides  a  shell  for  actions  on  the 
exported  data  updates 

#  K?  Field  Name 
|  1 

Model  Datatype 

( Domain | Lookup ( B | V  ^ Unit  Meas 

Description 

1  Y  Export  Table 

TABLE 

Table  currently  being  exported 

PROBLEM 

Data  Problems 

Edit  Limits 
Output 

Lists  problems. 

errors,  and  warnings  accumulated  by  the  data  checks 

#  K?  ^ Field  Name 

Model  Datatype 

j Doma in | Lookup ( B | V  ^ Unit  Meas 

Description 

1  Y  Directory 

2  Y  Table 

3  Y  Record 

4  Y  Field 

5  Y  Description 

A40 

A8 

Long>=0 

A25 

A150 

Directory  of  the  table  which  has  a  data 
problem 

Table  name  which  has  a  data  problem 

Record  number  which  has  a  data  problem 

Field  name  which  has  a  data  problem 
Description  of  the  data  problem 
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Directory  Type :  Tpfdd 


ACRGTYPE  Edit  Limits 

JOPES  Air  Cargo  Type  Update 


Lists  the  JOPES  air  cargo  types  (Bulk,  Oversize,  etc.)  and  their  maximum  dimensions 


#  K?  Field  Name 


Model  Datatype 


Domain  I  Lookup  B|V  Unit  Meas  Description 
_J _ ! - 1 — . — l - 1 - 


Air  Cargo  Type  Label 

A3 

Air  Cargo  Type 

A10 

Max  Length  Inches 

Short >-l 

Yes 

In 

Max  Width  Inches 

Short >=1 

Yes 

In 

Max  Height  Inches 

Short >=1 

Yes 

In 

Description 

A100 

Air  cargo  type  label  for  the  second 
position  of  the  cargo  category  code 
JOPES  air  cargo  type  such  as  Bulk, 

Oversize,  etc. 

Maximum  length  in  inches  for  this  air  cargo 
type 

Maximum  width  in  inches  for  this  air  cargo 
type 

Maximum  height  in  inches  for  this  air  cargo 
type 

Air  cargo  type  description 


AGGCAT 

Aggr  Cargo  Category 

Edit  Limits 

Provides  translations  for  aggregating  cargo  category 

#  K?  Field  Name 

i  i 

Model  Datatype  ^  Domain | Lookup } B | V  ^  Unit  Meas 

( Description 

1  Y  Cargo  Category 

A15 

Cargo  category  which  describes  the  kind  of 
cargo  being  transported 

2  Cargo  Category  Name 

3  Cargo  Category  Code 

4  Cargo  Category  Code  4 

5  Heavy  Lift  Code 

6  Max  Length  Inches 

7  Max  Width  Inches 

8  Max  Height  Inches 

9  Max  Weight  Ston 

10  Major  Category  Label 

11  Air  Cargo  Type  Label 

12  Unit  Class  Label 

13  Containerizability  Label 

14  Cargo  Category  Code  1 

15  Cargo  Category  Code  2 

16  Cargo  Category  Code  3 

17  Description 

18  Aggregated  Cargo  Category 


A15 

CCC 


Yes 


CCC4 

HEAVLIFT 

Short >=1  In 


Short >=1 

Short >=1 

Short >=1 

MAJCAT 

ACRGTYPE 

UNITCLAS 

CNTRTYPE 

CCC1 

CCC2 

CCC3 

A100 

A15 


In 


In 


Ston 


Short  cargo  category  name  for  use  in  GDAS 
JOPES  three-character  cargo  category  code 
describing  cargo  characteristics 
Customized  cargo  category  code  4  or  JOPES 
heavy  lift  and  dimension  code 
JOPES  heavy  lift  code  for  standard  cargo 
category 

Maximum  length  in  inches  for  this  cargo 
category  based  on  matching  Air  Cargo  Type 
in  ACRGTYPE,  Cargo  Category  Position  3  in 
CCC3,  and  Cargo  Category  Position  4  in  CCC4 
Maximum  width  in  inches  for  this  cargo 
category  based  on  matching  Air  Cargo  Type 
in  ACRGTYPE,  Cargo  Category  Position  3  in 
CCC3,  and  Cargo  Category  Position  4  in  CCC4 
Maximum  height  in  inches  for  this  cargo 
category  based  on  matching  Air  Cargo  Type 
in  ACRGTYPE,  Cargo  Category  Position  3  in 
CCC3 ,  and  Cargo  Category  Position  4  in  CCC4 
Maximum  weight  in  short  tons  for  this  cargo 
category  based  on  matching  Air  Cargo  Type 
in  ACRGTYPE,  Cargo  Category  Position  3  in 
CCC3 ,  and  Cargo  Category  Position  4  in  CCC4 
Major  cargo  category  label  corresponding  to 
the  first  position  of  the  JOPES  cargo 
category  code 

Air  cargo  type  label  for  this  second 
position  cargo  category  code 
Unit  equipment  classification  short  label 
(Ue,Ac,Nu)  for  the  second  position  of  the 
cargo  category  code 

Containerizability  type  corresponding  to 
the  third  position  of  the  cargo  category 
code 

First  position  of  the  JOPES  cargo  category 

defining  the  kind  of  cargo 

Second  position  of  the  JOPES  cargo  category 

defining  the  air  cargo  type  and  the  unit 

class 

Third  position  of  the  JOPES  cargo  category 
defining  cargo  containerizability 
Unit  level  code  description 
Aggregated  cargo  category  for  exporting  to 
a  scenario  database 


AGGMAJUN 

Aggr  Major  Unit 

Edit  Limits 

Provides  translations  for  aggregating  major  unit 

#  K?  Field  Name 

1 _ 1 _ 

Model  Datatype  f Domain | Lookup  B | V  Unit  Meas  ( Description 

1 

Y  Major  Unit 

A20 

2 

Unit  Type  Code 

A5TUUTC 

3 

Unit  Type  Function 

UTCFUNCT 

4 

Unit  Level  Code 

ULC 

5 

Deployment  Indicator  Code 

DEPLOY I C 

6 

Service  Code 

ORGCODE 

7 

Unit  Type  Short  Name 

A15 

8 

Unit  Type  Name 

A55 

9 

Non  Unit  Move  Type  Code 

NUMOVETP 

10 

Using  Organization 

ORGCODE 
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Major  unit  name  for  analysis  of  requirement 

closures  and  measures  of  effectiveness 

Matching  unit  type  code  for  this  major  unit 

Unit  type  code  first  position  which 

represents  the  functional  area  of  the  unit 

Unit  level  code  which  categorizes  the  type 

of  unit  according  to  stratum,  echelon,  or 

control  concentration 

JOPES  deployment  indicator  code  which 

characterizes  deployability 

JOPES  service  code  or  organization 

Unit  type  short  name 

Unit  type  name 

Non-unit  type  movement  code 

Non-unit  using  organization  for  a  non-unit 

movement 
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AGGMAJUN 

Edit  Limits 

Aggr  Major  Unit 

Provides  translations  for  aggregating  major  unit 


#  K?  Field  Name 


11  Supply  Class  Code 

12  Aggregated  Major  Unit 

13  Aggregated  RLD  Interval 

14  Aggregated  RDD  Interval 

15  Aggregated  EDD  Interval 

16  Aggregated  LAD  Interval 

17  Aggregated  RLD  Offset 

18  Aggregated  RDD  Offset 

19  Aggregated  EDD  Offset 

20  Aggregated  LAD  Offset 

21  Keep  Req  Id  Unique? 


Model  Datatype 


Domain| Lookup  B|V  Unit  Meas  Description 


Yesflag 


Non-unit  JOPES  supply  class  major  code 
which  categorizes  the  kind  of  cargo 
Aggregated  major  unit  for  export  to  a 
scenario  database 

Aggregate  RLD  interval  for  aggregating  the 
day,  for  example  5  means  every  5  days 
Aggregate  RDD  interval  for  aggregating  the 
day,  for  example  5  means  every  5  days 
Aggregate  EDD  interval  for  aggregating  the 
day,  for  example  5  means  every  5  days 
Aggregate  LAD  interval  for  aggregating  the 
day,  for  example  5  means  every  5  days 
Aggregate  RLD  offset  within  the  aggregation 
interval,  for  example  2  means  the  assigned 
day  is  2  plus  the  start  of  the  interval 
Aggregate  RDD  offset  within  the  aggregation 
interval,  for  example  2  means  the  assigned 
day  is  2  plus  the  start  of  the  interval 
Aggregate  EDD  offset  within  the  aggregation 
interval,  for  example  2  means  the  assigned 
day  is  2  plus  the  start  of  the  interval 
Aggregate  LAD  offset  within  the  aggregation 
interval,  for  example  2  means  the  assigned 
day  is  2  plus  the  start  of  the  interval 
Yes  if  unique  Requirement  Id  is  to  be 
maintained  during  aggregation,  blank  if 
requirements  can  be  aggregated  when  all 
data  elements  match  and  quantites  can  be 
totaled  by  category 


AGGMODE 

Aggr  Required  Mode 
#  K?  Field  Name 


Edit  Limits  I  Provides  translations  for  aggregating  required  transport  mode 


Model  Datatype 


Domain  I  Lookup  B|V  Unit  Meas  Description 


1  Y  Required  Mode 

2  Transport  Mode  Code 

3  Transport  Source  Code 

4  Aggregated  Required  Mode 


A15 

MODE_SRC 
MODE  SRC 


5  Description 


AGGNODE 
Aggr  Node 


#  K?  Field  Name 


Required  transport  mode 
Transport  mode  code 
Transportation  source  providing 
organization  code 

Aggregated  mode  for  export  to  a  scenario 
database 

Unit  level  code  description 


Edit  Limits  I  Provides  translations  for  aggregating  node  location 


2  Geolocation  Name 

3  Installation  Type  Code 

4  Country  State  Code 

5  Country  State  Short  Name 

6  Latitude 

7  Longitude 

8  Country  State  Long  Name 

9  Area  Responsibility  Code 

10  Army  Location  Code 

11  Aggregated  Node 

12  Computed  Node  Deviation 


Model  Datatype 

i  _ 


aggnode 


aggnodelat 
aggnode long 


aggnodeagg 

aggnodedist 


Domain | Lookup  B|V  Unit  Meas  Description 


A15  Detailed  node  representing  an  origin, 

destination,  POE,  POD,  POI,  etc. 

A17  Yes  Geolocation  name 

INSTTYPE  Yes  JOPES  geolocation  installation  type  code 

CNTRYST  Yes  JOPES  country/state  code 

A5  Yes  JOPES  country/state  short  name 

Lat  Yes  deg  min  H  Latitude  of  the  geolocation 

Lon  Yes  deg  min  H  Longitude  of  the  geolocation 

A15  Yes  JOPES  country/ state  long  name 

ORGCODE  JOPES  area  responsibility  code  identifying 

a  unified  or  specified  command 
A5  Army  location  code 

A15  Aggregated  node  for  export  to  a  scenario 

database 

Short>=0  nmi  Computed  great  circle  deviation  distance 

from  the  detailed  node  to  the  aggregated 
node,  in  nautical  miles 


Edit  Limits  i  Lists  the  three  character  JOPES  cargo  category  codes 


JOPES  Cargo  Cat  Code 


#  K?  Field  Name 


1  Y  Cargo  Category  Code 

2  Cargo  Category  Name 

3  Major  Category  Label 


Air  Cargo  Type  Label 
Unit  Class  Label 


Containerizability  Label 


Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 


A15 

MAJCAT 


JOPES  three-character  cargo  category  code 
describing  cargo  characteristics 
Short  cargo  category  name  for  use  in  GDAS 
Major  cargo  category  label  corresponding  to 
the  first  position  of  the  JOPES  cargo 
category  code 

Air  cargo  type  label  for  this  second 

position  cargo  category  code 

Unit  equipment  classification  label  (Ue, 

Ac,  Nu)  for  this  second  position  cargo 
category  code 

Containerizability  type  corresponding  to 
the  third  position  of  the  cargo  category 
code 
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CCC 

JOPES  Cargo  Cat  Code 


Edit  Limits 


Lists  the  three  character  JOPES  cargo  category  codes 


#  K?  Field  Name 


Model  Datatype 


Domain | Lookup  ^  B  |  V  ^  Unit  Meas  ^ Description 


7  Cargo  Category  Code  1 

8  Cargo  Category  Code  2 

9  Cargo  Category  Code  3 

10  Average  Mton  Per  Ston 

11  Average  SqFt  Per  Ston 

12  Average  SqFt  Per  Mton 

13  Description 


CCC1  Yes  First  position  of  the  JOPES  cargo  category 

defining  the  kind  of  cargo 

CCC2  Yes  Second  position  of  the  JOPES  cargo  category 

defining  the  air  cargo  type  and  the  unit 
class 

CCC3  Yes  Third  position  of  the  JOPES  cargo  category 

defining  cargo  containerizability 

Double>=0  Mton/Ston  Computed  average  Mton  per  Ston  ratio  for 

this  cargo  category  based  on  the  TUCHA 
records  in  the  TUCAT  table 

Double>=0  SqFt/Ston  Computed  average  SqFt  per  Ston  ratio  for 

this  cargo  category  based  on  the  TUCHA 
records  in  the  TUCAT  table 

Double  >=0  SqFt /Mton  Computed  average  SqFt  per  Mton  ratio  for 

this  cargo  category  based  on  the  TUCHA 
records  in  the  TUCAT  table 

AlOO  Description  of  the  cargo  category 


CCC1 

JOPES  Cargo  Cat  Posl 


Edit  Limits 


Lists  the  first  position  of  the  JOPES  cargo  category  code,  which  defines  the  kind  of 
cargo 


#  K?  Field  Name 


L_ 


Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 

_! _ I _  I  -1.-1 - 1 - 


1  Y  Cargo  Category  Code  1 

2  Major  Category  Label 

3  Description 


A1 

MAJCAT 

A30 


Yes 


First  position  of  the  JOPES  cargo  category 
code,  defining  the  kind  of  cargo 
Major  cargo  category  label  corresponding  to 
the  first  position  of  the  JOPES  cargo 
category  code 

Description  for  the  first  position  of  the 
JOPES  cargo  category  code 


CCC  2 

JOPES  Cargo  Cat  Pos2 


Edit  Limits 


Lists  the  second  position  of  the  JOPES  cargo  category  code,  which  defines  the  airlift 
cargo  type  and  the  unit  class  (Unit  Equip,  Acc  Supply,  Non  Unit) 


#  K?  Field  Name 


L_ 


Model  Datatype 


^ Domain | Lookup | B | V^Unit  Meas  ^ Description 


1  Y  Cargo  Category  Code  2 

2  Air  Cargo  Type  Label 

3  Unit  Class  Label 


A1 

ACRGTYPE 

UNITCLAS 


Yes 

Yes 


Second  position  of  the  JOPES  cargo  category 
code,  defining  the  air  cargo  type  and  the 
unit  class 

Air  cargo  type  label  for  this  second 

position  cargo  category  code 

Unit  equipment  classification  label  (Ue, 

Ac,  Nu)  for  this  second  position  cargo 
category  code 


CCC3 

JOPES  Cargo  Cat  Pos3 


Edit  Limits 


Lists  the  third  position  of  the  JOPES  cargo  category  code,  which  defines 
containerizability 


#  K?  Field  Name 


Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 


1  Y  Cargo  Category  Code  3 

2  Containerizability  Label 

3  Description 


Max  Length  Inches 
Max  Width  Inches 
Max  Height  Inches 


A1 

CNTRTYPE 

A35 


Short>-l 
Short >=1 
Short>=l 
Short  >*=1 


Yes 


Yes  In 
Yes  In 
Yes  In 
Yes  Ston 


Third  position  of  the  JOPES  cargo  category 
code,  defining  the  cargo  containerizability 
Containerizability  type  corresponding  to 
the  third  position  of  the  cargo  category 
code 

Description  for  the  third  position  of  the 

JOPES  cargo  category  code,  defining  the 

cargo  containerizability 

Maximum  length  in  inches 

Maximum  width  in  inches 

Maximum  height  in  inches 

Maximum  weight  in  short  tons 


CCC4 

Custom  Cargo  Cat  4 

Edit  Limits 

Lists  a  customizable  fourth  position  cargo 
cargo  item  dimensions 

category  code,  which  specifies  user-definable 

#  K?  Field  Name 

1 _ l - 

Model  Datatype  Domain | Lookup  B|V  Unit  Meas 

_ I _ j _ ! _ i . -.1 - 

Description 

1  Y  Cargo  Category  Code  4 


2  Max  Length  Inches 

3  Max  Width  Inches 

4  Max  Height  Inches 

5  Max  Weight  Ston 

6  Description 


A10 


Short >=1 
Short>=l 
Short >=1 
Item  Ston 
AlOO 


Yes  In 
Yes  In 
Yes  In 
Yes  Ston 


which  defines  dimension  limits  for  detailed 
cargo  items 

Maximum  length  in  inches 
Maximum  width  in  inches 
Maximum  height  in  inches 
Maximum  weight  in  short  tons 
Description  of  the  customizable  cargo 
category  code 


CLASSIFC 

JOPES  Classif  Code 

Edit  Limits 

Lists  the  JOPES 

security  classification  codes 

#  K?  Field  Name 

i  t 

Model  Datatype 

^  Domain  |  Lookup  ( B  |  V  ^  Unit  Meas  ^  Description 

1  Y  Security  Classif  Code 

2  Security  Classification 


A1 

A12 


JOPES  security  classification  code 
JOPES  security  classification  label 
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CNTRTYPE 
Container  Type 

Edit  Limits 

Lists  the  containerizability  types  corresponding  to  the  third  position  of  the  JOPES 

Cargo  Category  Code 

•*  K?  Field  Name 

i 

Model  Datatype 

Domain | Lookup  B|V  Unit  Meas 

Description 

J _ _ . _ _ 

1  Y  Containerizability  Label 

A4 

Containerizability  type  corresponding  to 

the  third  position  of  the  cargo  category 

code 

2  Description 

A3  5 

Description  of  the  containerizability  type 

1  CNTRYST 

Edit  Limits 

Lists  the  JOPES  country  state  codes  and  names  « 

JOPES  Country  State 

#  K?  Field  Name 
i 

Model  Datatype 

^ Domain | Lookup  B|V  Unit  Meas 

Description 

j 

1  Y  Country  State  Code 

A2 

JOPES  country/state  code 

2  Country  State  Short  Name 

AS  Yes 

JOPES  country/state  short  name 

3  Country  State  Long  Name 

A15  Yes 

JOPES  country/ state  long  name 

4  GSA  State  Code 

A2 

GSA  state  code 

5  Navy  Ocean  Area  Code 

A2 

Navy  ocean  area  code,  if  any 

1  CRGDTLVL 

Edit  Limits 

Lists  the  JOPES  TUCHA  and  TPFDD  cargo  detail 

levels 

JOPES  Crg  Detail  Lev 

#  K?  Field  Name 

i _ 

Model  Datatype 

Domain | Lookup  B|V^Unit  Meas 

( Description 

1  Y  Level  of  Detail 

A1 

JOPES  cargo  detail  level  number  for  TUCHA 

and  TPFDD  data 

2  TUCHA  Record  Type 

A4 

TUCHA  record  type  code  matching  this  level 

of  detail 

3  Cargo  Level  of  Detail 

A25 

JOPES  cargo  detail  level  for  TUCHA  and 

TPFDD  data 

4  Description 

A60 

Description  of  the  JOPES  cargo  detail  level 

for  TUCHA  and  TPFDD  data 

DATATEST 

Edit  Limits 

Lists  the  available  data  test  and  checking  procedures  for  selection  1 

Data  Test  Procedures  Display  Onl 

#  K?  Field  Name 

i 

( Model  Datatype 

Domain  1  Lookup  Bjv  Unit  Meas 

t  t  i 

Description 

1 

Y  Test  Type 

A15 

2 

Y  Table 

TABLE 

3 

Y  Data  Test 

A30 

4 

Last  Run  Date 

Date 

5 

Test  Severity 

A20 

6 

Description 

A255 

7 

Procedure 

PAL 

Type  or  applicability  of  the  data  test 
procedure 

Target  table  for  the  data  test 

Data  test  or  checking  procedure  name  which 

is  applied  to  the  target  table 

Last  run  date  for  this  data  test  or 

checking  procedure 

Data  test  severity  level 

Description  of  this  data  test  or  checking 
procedure 

Procedure  or  query  specification  for  this 
data  test  or  checking  procedure 


DELREAS 

NonUnit  Delay  Reason 

Edit 

Limits 

Lists  the  JOPES  codes  for  non-unit  intermediate  stop  delay  reasons 

#  K?  Field  Name 

_ i _ 

Model  Datatype 

( Domain | Lookup (B|V(Unit  Meas 

Description 

1  Y  Non  Unit  POI  Delay  Reason 

A1 

JOPES  code  for  non-unit  port  of 

intermediate  (POI)  stop  delay  reason 

2  Description 

A40 

Description  of  the  non-unit  intermediate 

stop  delay  reason 

DELTYPE 

Edit 

Limits 

Lists  the  JOPES  codes  for  unit  intermediate  stop  delay  type,  either  total  force  or  force] 

Unit  Delay  Type 

increments 

.  . .  1 

#  K?  Field  Name 

_ i _ 

( Model  Datatype 

( Domain | Lookup  ^  B | V  ^ Uni t  Meas 

( Description 

1  Y  Unit  POI  Delay  Type 

A1 

JOPES  code  for  unit  port  of  intermediate 

(POI)  stop  delay  type,  either  total  force 

or  increments 

2  Description 

A60 

Description  of  the  unit  intermediate  stop 

delay  type 

DEPLOY I C 

Edit 

Limits 

Lists  the  JOPES  deployment  indicator  codes  which  characterize  deployability  j 

JOPES  Deploy  Indie 

. .  J 

#  K?  Field  Name 
_ i _ 

Model  Datatype 

( Domain | Lookup ( B | V  ^  Unit  Meas 

( Description 

Deployment  Indicator  Code 

A1 

JOPES  deployment  indicator  code  which 
characterizes  deployability 

Deployment  Label 

A20 

Short  label  for  the  JOPES  deployment 
indicator  code  which  characterizes 
deployability 

Description 

A100 

Description  of  the  JOPES  deployment 
indicator  code  which  characterizes 
deployability 
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DISCHCFG  Edit  Limits 

JOPES  Discharge  Code 

Lists  the  JOPES  discharge  constraint  codes 

¥  K?  Field  Name  Mode 

»1  Datatype  Domain | Lookup ^BjV^Unit  Meas  ^ Description 

1  Y  Discharge  Constraint  Code  A2  JOPES  discharge  constraint  code 

2  Discharge  Constraint  A50  JOPES  discharge  constraint 

FIC  Edit  Limits 

JOPES  Force  Indicate 

Lists  the  JOPES  force  indicator  codes 

#  K?  Field  Name  Mod* 

*1  Datatype  Domain | Lookup  B|v  Unit  Meas  ^ Description 

X  Y  Force  Indicator  Code  0,9  JOPES  force  indicator  code 

2  Description  A70  Description  of  the  force  indicator  code 

FUELTYPE  Edit  Limits 

Fuel  Type  Code 

Lists  the  JOPES  fuel  types 

#  K?  Field  Name  Model  Datatype  Domain | Lookup  B|V  Unit  Meas  Description 

1  Y  Fuel  Type  Code  A3  JOPES  fuel  type  code 

2  Description  ASO  Fuel  type  description  or  nomenclature 

GEODATE  Edit  Limits 

Geoloc  Date 

Stores  the  geoloc  file  date 

#  K?  Field  Name  Model  Datatype  Domain | Lookup  B|v  Unit  Meas  Description 

\  i  i  »  i  i - - 

1  Y  Geoloc  File  Date  Date  Date  of  the  last  imported  geoloc  file 

GEOLOC  Edit  Limits 

Geolocation 

Stores  the  imported  geoloc  data  from  the  JOPES  Geofile 

#  K?  Field  Name  Model  Datatype  Domain | Lookup  B|V  Unit  Meas  Description 

*  i _ l - 1 - - - u - * - 1 - — — - 

1  Y 

Geoloc 

A4 

2 

Geolocation  Name 

A17 

3 

Installation  Type  Code 

INSTTYPE 

4 

Country  State  Code 

CNTRYST 

5 

Country  State  Short  Name 

A5 

6 

Province  Code 

A3 

7 

Province  Name 

A14 

8 

Tactical  Zone 

A2 

9 

Latitude 

Lat 

10 

Longitude 

Logistic  Planning  Code 

Lon 

11 

LOGCODE 

12 

Prime  Geoloc 

GEOLOC 

13 

Record  Owner 

A6 

14 

ICAO 

A4 

15 

GSA  State  Code 

A2 

16 

GSA  City  Code 

A4 

17 

GSA  County  Code 

A3 

18 

Date  Record  Changed 

Date 

19 

Date  Record  Created 

Date 

20 

Date  Geoloc  Cancelled 

Date 

21 

Country  State  Long  Name 

A15 

22 

Area  Responsibility  Code 

ORGCODE 

23 

Record  Status  Code 

A1 

24 

Security  Classification 

CLASSIFC 

25 

Army  Location  Code 

A5 

26 

Navy  Ocean  Area  Code 

A2 

JOPES  geoloc  code  for  a  geographic  location 
Yes  Geolocation  name 

Yes  Installation  type  code  which  identifies  the 

type  of  installation 

Yes  Country/ state  code  which  identifies  the  geo 

-political  area  or  state 
Yes  Country/state  short  name 

Province  code  identifying  the  political 
subdivision  of  the  country  or  state 
Province  name  identifying  the  political 
subdivision  of  the  country  or  state 
Tactical  zone  code  which  identifies  the 
military  tactical  zone 
Yes  deg  min  H  Latitude  of  the  geolocation 
Yes  deg  min  H  Longitude  of  the  geolocation 
Yes  Logistic  planning  code  for  military  use 

Yes  Prime  geolocation  code  for  grouping  at  a 

location 

Unit  identification  code  (UIC)  of  the 
organization  responsible  for  reporting  the 
data  on  this  record 

International  Civil  Aviation  Organization 
Code  used  to  identify  airports 
General  Services  Administration  (GSA)  state 
code  in  the  U.S. 

General  Services  Administration  (GSA)  state 
city  in  the  U.S. 

General  Services  Administration  (GSA) 
county  code  in  the  U.S. 

Yes  Date  record  was  last  changed 

Yes  Date  record  was  first  created 

Date  this  geoloc  was  cancelled 
Yes  Country/ state  long  name 

JOPES  area  responsibility  code  identifying 
a  unified  or  specified  command 
Record  status  code,  A  indicates  active,  C 
indicates  cancelled 

Security  classification  for  this  record 
Army  location  code 
Navy  ocean  area  code 


HEAVLIFT 

JOPES  Heavy  Lift 

Edit  Limits 

Lists  the 

JOPES  heavy  lift  codes 

#  K?  Field  Name 

1 _ 1 _ 

Model  Datatype 

( Domain | Lookup ( B | V ^ Unit  Meas  description 

1  Y  Heavy  Lift  Code 

2  Length  Max  Inches 

3  Weight  Max  Ston 


A1 

Short>=l  Yes  In 

Short>*l  Yes  Ston 


JOPES  heavy  lift  and  dimension  code 
Maximum  length  dimension  in  inches  for  this 
heavy  lift  code 

Maximum  weight  in  short  tons  for  this  heavy 
lift  code 


45 


Directory  Type:  Tpfdd 


Edit  Limits  ^Provides  table,  record,  and  field  specifications  for  importing  data  from  external 


Import  Specification 


**  K?  Field  Name 

-  » _ 

1  Y  Import  Type 

2  Y  Target  Table 

3  Y  Record  Variation 

4  Y  Field  Name 

5  Blanks  Allowed? 

6  Updates  Allowed? 

7  Start  Column 

8  Stop  Column 

9  Start  Line 

10  Stop  Line 

11  Translation  Name 


12  Comment 


databases 


Model  Datatype 


Domain I  Lookup  B|V  Unit  Meas  Description 

j _ : _ i _ i - 1 - 

A15  Import  type 


Short >=0 
Short >=0 
Short >=0 
Short >=0 
A20 


Import  type  which  corresponds  to  a  single 
data  file  for  importing 

Target  table  that  receives  the  imported  and 
translated  data 

Import  name  which  specifies  one  type  of 
import  for  the  ASCII  file 

Target  field  that  receives  the  inport ed  and 
translated  data 

Yes  if  blanks  are  allowed,  blank  otherwise 
(should  be  blank  for  all  key  fields) 

Yes  if  updates  are  allowed  to  existing 

records  with  matching  key  fields,  no  if 

original  data  is  not  to  be  changed 

Starting  column  in  the  input  record  for  the 

ASCII  characters  to  be  translated 

Stop  column  in  the  input  record  for  the 

ASCII  characters  to  be  translated 

First  line  number  in  the  ASCII  file  for 

this  import  type  to  process 

Last  line  number  in  the  ASCII  file  for  this 

import  type  to  process 

Translation  name,  if  any,  for  converting 
the  input  ASCII  string  to  an  output 
datatype  (blank  means  no  translation 
performed;  "OTABLENAME"  indicates  a  table- 
driven  translation;  * FUNCTION  means  call  a 
function) 

Comment,  if  any,  describing  this  import 
record 


INSTTYPE 

Edit  Limits 

Installation  Type 

#  K?  Field  Name 


1  Y  Installation  Type  Code 

2  Installation  Type 


Lists  the  JOPES  Geolocation  installation  type  codes 


Model  Datatype  Domain | Lookup  B|V  Unit  Meas  Description 


JOPES  geolocation  installation  type  code 
JOPES  geolocation  installation  type 


LOADCFG 

Edit  Limits 

JOPES  Load  Config 

#  K?  Field  Name  Model  Datatype 

i  _ i _ _ _ _ _ 


1  Y  Load  Configuration  Code 

2  Load  Configuration 


LOGCODE  Edit  Limits  Lists  the  JOPES 

JOPES  Logistics  Code 


Lists  the  JOPES  load  configuration  codes 


Model  Datatype  Domain | Lookup  B|V  Unit  Meas  Description 


#  K?  Field  Name 


1  Y  Logistics  Planning  Code 

2  Description 


Model  Datatype 


MAJCAT  Edit  Limits  Lists  the  major 

Major  Cargo  Category  category  code 


#  K?  Field  Name 

i  i 


I  Y  Major  Category  Label 


Model  Datatype 


2  Description 


MODECODE 

JOPES  Move  Type  Code 


#  K?  Field  Name 

i  i 


1  Y  Mode  Code 

2  Transport  Mode 


MODE_SRC 

JOPES  Mode  &  Source 


#  K?  Field  Name 


Ai  JOPES  load  configuration  code 

A40  JOPES  load  configuration  description 


Geolocation  logistics  planning  codes 


Domain | Lookup  B|V  Unit  Meas  Description 


A2  JOPES  geolocation  logistics  planning  code 

A30  Description  of  the  JOPES  geolocation 

logistics  planning  code 


cargo  categories  corresponding  to  the  first  position  of  the  JOPES  cargo 


Domain | Lookup  B|V  Unit  Meas  Description 

j _ ! _ i  i _ 1 - - - — - 

A4  Major  cargo  category  label  corresponding  to 

the  first  position  of  the  JOPES  cargo 
category  code 

A30  Description  of  the  major  cargo  category 


Edit  Limits  Lists  the  JOPES  transport  mode  codes 


Model  Datatype  Domain | Lookup  B|V  Unit  Meas  Description 


JOPES  transport  mode  code 
Transport  mode 


Edit  Limits  Lists  the  JOPES  transport  mode  and  source  code  combinations 


Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 


1  Y  Transport  Mode  Code 

2  Y  Transport  Source  Code 

3  Description 


MODECODE 

TRANPSRC 


Transport  mode  code 

Transport  source  providing  organization 
code 

Description  of  this  transport  mode  and 
transportation  providing  organization 
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MREQNODE 
Merged  Req  Node 


#  K?  Field  Name 
_ I _ 

1  Y  Requirement  Id 

2  Y  Cargo  Class 


Edit  Limits  Lists  detailed  required  intermediate  POE  or  POD  nodes  or  ports  prior  to  aggregation  for 
Output  movement  requirements  having  POE/POD  nodes  and  modes _ 

Model  Datatype  Domain | Lookup  t  B | V  ^  Unit  Meas  Description  _ _ 


5  Required  Node 

6  Required  Mode  to  Node 

7  Required  Config  to  Node 

8  Stage  Name 

9  Description 


MREQUIRE 


DayToHr 


DayToHr 


A15AGGN0DE 


A15AGGM0DE 


day  (hr) 


day  (hr) 


Movement  requirement  identifier  with 
intermediate  ports  or  staging 
Cargo  class  for  which  the  required  node 
applies 

Latest  arrival  day  at  this  required  port 
node  (the  LAD  is  used  to  determine  the 
order  in  which  required  nodes  are  visited) 
Earliest  arrival  day  at  this  required  port 
node,  if  any 

Required  intermediate  POE/POD  node  or  port 
for  this  movement  requirement 
Required  transport  mode  specified  for 
delivery  to  the  intermediate  node,  if  any 
(blank  permits  the  use  of  any  mode  for 
delivery) 

Required  configuration  specified  for 
delivery  to  the  intermediate  node,  if  any 
(blank  permits  the  use  of  any 
configuration) 

Staging  deployment  name  if  multiple 
requirements  are  staged  together  at  this 
node  (the  STAGE  record  must  have  the  same 
node  as  in  REQNODE) 

Description  of  this  intermediate  node,  e.g. 
consolidation,  container  stuffing,  mode 
change,  re -configuration,  combat  loading, 
etc. 


MREQQUAN 

Edit  Limits 

Merged  Req  Quantity 

Output 

#  K?  Field  Name 

I  I 


1  Y  Requirement  Id 

2  Y  Cargo  Category 

3  Y  Cargo  Measure 

4  Quantity 


MREQUIRE 

Merged  Requirement 

#  K?  Field  Name 
I _ I - 

1  Y  Requirement  Id 

2  Ma j  or  Unit 

3  Origin 

4  Destination 

5  RLD 


cargo  category  for  export  to  scenario  directories 


Model  Datatype  Domain | Lookup  B|V  Unit  Meas  Description 


MREQUIRE 

A15AGGCAT 


Double >=0 


Requirement  identifier  for  the  cargo 
Cargo  category  which  describes  the  kind  of 
cargo  being  transported 

Dimensional  measure  for  this  requirement 
and  cargo  category 

Requirement  category  quantity  or  dimension 
in  this  unit  of  measure 


Edit  Limits 
Output 


Provides  detailed  information  prior  to  aggregation  for  each  movement  requirement  or 
package  for  export  to  scenario  directories 


Model  Datatype 


Domain j Lookup  B|V  Unit  Meas  Description 


A15 

A20AGGMAJUN 

A15AGGN0DE 

A15AGGN0DE 

DayToHr 

DayToHr 


DayToHr 


8  Computed  Closure  Day 


9  Priority  Order 


DayToHr 


10  Aggregated  Requirement  Id  A15 


NUMOVETP  Edit  Limits  Lists  the  JOPES  non-unit  type  movement  codes 

JOPES  Non  Unit  Type 


Movement  requirement  or  package  id 
Major  unit  associated  with  this  movement 
requirement 

Starting  origin  of  the  requirement 
Final  destination  of  the  requirement 
day  (hr)  Ready  to  load  day  or  earliest  day  the 
requirement  is  available  at  its  origin 
day  (hr)  Required  delivery  day  of  the  packaged 

requirement  at  its  destination  including 
time  for  assembly 

day  (hr)  Earliest  allowed  delivery  day  of  the 

requirement  at  its  destination  prior  to 
assembly 

day  (hr)  Closure  day  for  the  requirement  based  on 

the  closure  minimum  %  requirement  specified 
in  the  REQTYPE  table 
Relative  priority  order  for  this 
requirement  as  a  secondary  sort  after  the 
Target  Lift  Date  (one  means  first  priority 
in  assigning  lift  assets,  blank  defaults  to 
the  priority  order  of  the  requirement  type) 
Aggregated  requirement  identifier  for 
export  to  a  scenario  database 


#  K?  Field  Name 

l  t 


1  Y  Non  Unit  Move  Type  Code 

2  Cargo  or  Pax 

3  Movement  Type  Label 


4  Non  Unit  Movement  Type 


Model  Datatype  Domain | Lookup  B|V  Unit  Meas  Description 


Non -unit  movement  type  code 

Cargo  or  pax  indicator  for  this  non-unit 

movement  type  code 

Non-unit  movement  type  label,  also  used  as 
the  default  Aggregated  Major  Unit  in 
AGGMAJUN  for  non-unit  movements 
Non-unit  movement  type 


47 


Directory  Type :  Tpf dd 


NURECTYP  Edit  Limits 

Non  Unit  Record  Type 

Lists  the  JOPES  TPFDD  non-unit  record  types  for  Pax  and  Cargo 

1  K?  Field  Name  Mod* 

;1  Datatype  Domain | Lookup ^ B | V ^ Unit  Meas  ^ Description 

1  Y  Non  Tin  it  farao/Pax  Code  A1  TPFDD  non-unit  record  type  code  (G  or  J) 

2  Non  Unit  Carlo/Pax  A10  TPFDD  non-unit  record  type  code  (Cargo  or 

Pax) 

ORGCODB  Edit  Limits 

JOPES  Organization 

Lists  the  JOPES  organization  and  service  codes 

#  K?  Field  Name  Mod( 

ii  i 

si  Datatype  ^  Domain  j  Lookup ( B | V  ^  Unit  Meas  Description 

1 

Y  Organization  Code 

A1 

2 

Force  Providing  Org 

A25 

3 

Non  Unit  Cargo  Prov  Org 

A25 

4 

Non  Unit  Person  Prov  Org 

A25 

5 

Service  or  Using  Org 

A25 

6 

OPLAN  Id  Min 

A5 

7 

OPLAN  Id  Max 

A5 

8 

ULN  Force  Id  Min 

A1 

9 

ULN  Force  Id  Max 

A1 

10 

CIN  or  PIN  Min 

A5 

11 

CIN  or  PIN  Max 

A5 

Force  providing  organization  or  service 
Non-unit  cargo  providing  organization  or 
service 

Non-unit  personnel  providing  organization 
or  service 

Using  organization  of  service 

Minimum  possible  OPLAN  identifier  for  this 

service  or  force  organization 

Maximum  possible  OPLAN  identifier  for  this 

service  or  force  organization 

Minimum  possible  Unit  Line  Number  (ULN)  and 

force  module  identifier  for  this  service  or 

organization 

Maximum  possible  Unit  Line  Number  (ULN)  and 
force  module  identifier  for  this  service  or 
organization 

Minimum  possible  Cargo  Item  Number  (CIN)  or 
Personnel  Item  Number  (PIN)  assignment  for 
this  service  or  organization 
Maximum  possible  Cargo  Item  Number  (CIN)  or 
Personnel  Item  Number  (PIN)  assignment  for 
this  service  or  organization 


PIC  Edit  Limits 

JOPES  Parent  Indicat 


Lists  the  JOPES  parent  indicator  codes  which  describe  subordinate  splitting 


#  K?  Field  Name 


L_ 


Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 


1  Y  Parent  Indicator  Code 

2  Description 


A1 

A25 


JOPES  parent  indicator  code  for  describing 
subordinate  splitting 

Description  for  this  parent  indicator  code 
for  describing  subordinate  splitting 


POILOC 

JOPES  POI  Location 


Edit  Limits 


Lists  the  JOPES  intermediate  port  location  codes 


#  K?  Field  Name 
1 _ l - 


Model  Datatype 
-J - 


Domain | Lookup  B|V  Unit  Meas  Description 
j[ _  i  i _ I - 


1  Y  POI  Location  Order  Code 

2  POI  Location  Order 


A1 

A15 


Port  of  intermediate  debarkation  (POI) 
location  code 

Intermediate  port  location  description 


RECCODE  Edit  Limits 

Lists  the  JOPES  record  indicator  codes 

JOPES  Record  Indicat 

#  K?  Field  Name 
l _ I - 


Model  Datatype 


^ Domain | Lookup | B 1 V | Unit  Meas  < Description 


1  Y  Record  Completion  Code 

2  Record  Completion  Status 


A1 

A30 


TUCHA  record  indicator  code  indicating  F2 
and  F3  counts 

TUCHA  record  indicator  code  indicating  F2 
and  F3  counts 


STOPCODE 

Edit  Limits 

Lists  the  JOPES  stop  reason  codes 

JOPES  Stop  Code 

#  K?  Field  Name 
i - 1 - 


Model  Datatype 


Domain [ Lookup  Blv  Unit  Meas  Description 
j _  i  t _ I - 


1  Y  Stop  Code 

2  Stop  Description 


A1 

A15 


JOPES  stop  reason  code 
JOPES  stop  reason  description 


SUPCLAS1  Edit  Limits 

JOPES  Supply  Class  1 


Lists  the  JOPES  major  supply  class  code  in  position  1 


#  K?  Field  Name 
i _ i - 


Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 


1  Y  Supply  Class  Code 

2  Supply  Class  Label 

3  Description 


A20 

A40 


JOPES  supply  class  major  code  which 
categorizes  the  kind  of  cargo 
Major  supply  class  descriptive  label 
JOPES  supply  class  major  category 
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SUPCLASS  Edit  Limits 

JOPES  Supply  Class 


Lists  the  JOPES  two-character  supply  class  and  subclass  codes 


K?  Field  Name 


Model  Datatype _ ^  Domain  ]  Lookup  ^  B  [  V  ^  Unit  Meas  ^ Description 


1  Y  Supply  Class/Subclass 

2  Supply  Class  Code 

3  Description 


A2 

SUPCLAS1 

ABO 


Yes 


JOPES  supply  class  and  subclass  code  which 

categorize  the  kind  of  cargo 

JOPES  supply  class  major  code  which 

categorizes  the  kind  of  cargo 

Supply  class  and  subclass  description 


TPID 

TPFDD  Ident 

Edit  Limits 

Stores  the 

imported  TPFDD  Identifier  record 

#  K?  Field  Name 

1 _ 1 _ 

Model  Datatype 

i 

Domain | Lookup ( B | V  ^  Unit  Meas  ( Description 

1  Y  OPLAN 

2  Force  Record  Count 

3  Non  Unit  Record  Count 

4  Last  Sector  Address 


A5 

Long>-0 

Long>=0 

Long>=0 


Operations  plan  number 

Count  of  the  total  number  of  force  or  unit 
records  in  the  TPFDD 

Count  of  the  total  number  of  supply  or  non 
unit  records  in  the  TPFDD 
Sector  number  of  the  last  record  in  the 
TPFDD  file 


TPNONUNT  Edit  Limits 

TPFDD  Non  Unit 

Stores  the  imported  TPFDD  Non  Unit  cargo  and 

pax  records 

#  K? 

Field  Name  Model  Datatype  Domain [ Lookup  B|V  Unit  Meas 

Description 

1  Y 

OPLAN 

TPID 

Operations  plan  number 

2  Y 

Movement  Id 

A7 

Movement  identifier  consisting  of  the  using 
organization,  the  movement  type  code,  and 
the  sequence  number  concatenated  together 

3 

Using  Organization 

ORGCODE 

Code  identifying  the  service  or  activity 
that  will  use  this  nonunit  related  cargo  or 
personnel 

4 

Movement  Type  Code 

NUMOVETP 

Movement  code  type  that  categorizes  the 
functional  use  of  the  cargo /personnel 

5 

Sequence  Number 

Long>=0 

Sequencing  number  that  uniquely  identifies 
this  record  with  a  using  organization  and 
movement  type 

6 

Non  Unit  Cargo/ Pax  Code 

NURECTYP 

Record  type 

7 

Origin  Geoloc 

GEOLOC 

Yes 

Origin  geoloc  code 

8 

Origin  Country  State 

CNTRYST 

Origin  country/state  code 

9 

POE  Geoloc 

GEOLOC 

POE  geoloc  code 

10 

POE  Country  State 

A2 

POE  country/state  code 

11 

POE  ALD 

Short +/- 

day 

POE  available  to  load  date  (ALD) 

12 

Computed  POD  EDD 

Short*/ - 

day 

The  computed  earliest  delivery  day  (EDD) 
the  unit  could  possibly  arrive  at  the  POD 
based  on  the  POE  ALD 

13 

POE  Preferred  Mode 

MODE  SRC 

Preferred  mode  of  transport  to  the  POE 

14 

POE  Preferred  Source 

MODE_SRC 

Preferred  organizational  source  of 
transport  to  the  POE 

15 

POE  Alt  Geoloc 

GEOLOC 

POE  alternate  geoloc  code 

16 

POE  Alt  Country  State 

A2 

POE  alternate  country/state 

17 

POD  Geoloc 

GEOLOC 

POD  geoloc  code 

18 

POD  Country  State 

CNTRYST 

POD  country/state  code 

19 

POD  EAD 

Short*/- 

day 

POD  earliest  arrival  date  (EAD) 

20 

POD  LAD 

Short +/- 

day 

Latest  arrival  date  (LAD)  by  which  the 
requirement  must  arrive  and  complete 
unloading  at  the  POD 

21 

POD  Closure  Day 

Short*/ - 

day 

POD  feasible  arrival  date  (FAD)  by  which 
the  requirement  completes  unloading  at  the 
POD 

Preferred  mode  of  transport  to  the  POD 

22 

POD  Preferred  Mode 

MODE  SRC 

23 

POD  Preferred  Source 

M0DE_SRC 

Preferred  organizational  source  of 
transport  to  the  POD 

24 

POD  Alt  Geoloc 

GEOLOC 

POD  alternate  geoloc  code 

25 

POD  Alt  Country  State 

A2 

POD  alternate  country/state 

26 

Dest  Geoloc 

GEOLOC 

Yes 

Destination  geoloc  code 

27 

Dest  Country  State 

CNTRYST 

Destination  country/state  code 

28 

Dest  RDD 

Short +/- 

Yes  day 

Required  delivery  day  (RDD)  by  which  the 
requirement  must  arrive  and  complete 
unloading  at  the  destination 

29 

Dest  Preferred  Mode 

M0DE_SRC 

Preferred  mode  of  transport  to  the 
destination 

30 

Dest  Preferred  Source 

M0DE_SRC 

Preferred  organizational  source  of 
transport  to  the  destination 

31 

Pax  Needing  Transport 

Long>=0 

Pax 

Number  of  personnel  requiring  non-organic 
transport  when  this  requirement  moves 

32 

Cargo  Category  Code 

CCC 

Yes 

JOPES  three -character  cargo  category  code 
describing  cargo  characteristics 

33 

Cargo  Category  Code  1 

CCC1 

Yes 

First  position  of  the  JOPES  cargo  category 
code,  defining  the  kind  of  cargo 

34 

Cargo  Category  Code  2 

CCC2 

Yes 

Second  position  of  the  JOPES  cargo  category 
code,  defining  the  air  cargo  type  and  the 
unit  class 

35 

Cargo  Category  Code  3 

CCC3 

Yes 

Third  position  of  the  JOPES  cargo  category 
code,  defining  the  cargo  containerizability 

36 

Heavy  Lift  Code 

HEAVLIFT 

Yes 

Heavy  lift  category  code  corresponding  to 
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TPNONUNT 

TPFDD  Non  Unit 

Edit  Limits 

Stores  the 

imported  TPFDD  Non  Unit  cargo  and  pax  records 

?  K?  Field  Name 

Mode 

i 

il  Datatype 

Domain | Lookup  BlV^Unit  Meas  description 

the  heaviest  item  and  the  largest  item 

37 

Supply  Class  Code 

SUPCLAS1 

38 

Supply  Class/Subclass 

SUP CLASS 

39 

Area  SqFt 

Double>=0 

40 

Weight  Ston 

Double >=0 

41 

Volume  Mton 

Double >-0 

42 

Bulk  POL  Cbbl 

Double >=0 

43 

Project  Code 

A3 

44 

Date  Created 

Date 

45 

Date  Last  Changed 

Date 

46 

Providing  Organization 

ORGCODE 

47 

Fuel  Type  Code 

FUELTYPE 

48 

POI  Reason 

DELREAS 

49 

POI  Geoloc 

GEOLOC 

50 

POI  Country  State 

CNTRYST 

51 

POI  Preferred  Mode 

MODE_SRC 

52 

POI  Preferred  Source 

MODE_SRC 

53 

POI  Days  Delay 

Short >=0 

54 

POI  Location  Order  Code 

POILOC 

55 

Description 

A15 

dimension 

JOPES  supply  class  major  code  which 
categorizes  the  kind  of  cargo 
JOPES  supply  class  and  subclass  code  which 
categorize  the  kind  of  cargo 
Yes  SqFt  Cargo  area  in  square  feet 

Yes  St  on  Cargo  weight  in  short  tons 

Yes  Mton  Cargo  volume  in  measurement  tons 

Yes  CBbl  Cargo  bulk  petroleum,  oil,  and  lubrication 

(POL)  in  hundreds  of  barrels 
Project  code  used  to  identify  special 
projects 

Date  this  record  was  created 
Date  this  record  was  last  changed 
Providing  organization  or  activity  that  is 
responsible  for  providing  the  cargo  or 
personnel  from  this  requirement 
Fuel  type  code 

Reason  for  intermediate  stop  delay 

Port  of  intermediate  (POI)  location  geoloc 

code 

Intermediate  port  country/ state  code 
Preferred  mode  of  transport  to  the 
intermediate  location 
Preferred  organizational  source  of 
transport  to  the  intermediate  location 
day  Days  delay  at  the  intermediate  location 

Code  describing  the  location  of  the 
intermediate  port  relative  to  the  POE  and 
POD 

Description  of  this  cargo  or  personnel 
increment 


TPSRFCAT 

TPFDD  SRF  Category 

Edit  Limits 

Stores  the 

imported  TPFDD  SRF  category  records  for  non-standard  units 

#  K?  Field  Name 

1 - 1 - 

Model  Datatype 
_ l _ _ _ 

Domain | Lookup  B^Unit  Meas  description 

1  Y  OPLAN 

TPUNIT 

2  Y  Unit  Line  Number 

TPUNIT 

3  Y  Cargo  Category  Code 

CCC 

4  Cargo  Category  Code  1 

CCC1 

Yes 

5  Cargo  Category  Code  2 

CCC2 

Yes 

6  Cargo  Category  Code  3 

CCC3 

Yes 

7  Area  SqFt 

Double >=0 

Yes  SqFt 

8  Weight  Ston 

Double>=0 

Yes  Ston 

9  Volume  Mton 

Double >-0 

Yes  Mton 

10  Bulk  POL  Cbbl 

Double>=0 

Yes  CBbl 

11  Heavy  Lift  Code 

HEAVLIFT 

Yes 

12  Actual  Detail  Records 

Short>=0 

13  Required  Detail  Records 

Short >=0 

14  Is  Aggregated  Flag 

A1 

15  Date  Last  Changed 

Date 

Operations  plan  number 
Concatenated  force  identifier  or  Unit  Line 
Number  (TJLN)  consisting  of  the  force 
requirement  number,  fragmentation  code,  and 
insertion  code 

JOPES  three- character  cargo  category  code 

describing  cargo  characteristics 

First  position  of  the  JOPES  cargo  category 

code,  defining  the  kind  of  cargo 

Second  position  of  the  JOPES  cargo  category 

code,  defining  the  air  cargo  type  and  the 

unit  class 

Third  position  of  the  JOPES  cargo  category 
code,  defining  the  cargo  containerizability 
Cargo  area  in  square  feet 
Cargo  weight  in  short  tons 
Cargo  volume  in  measurement  tons 
Cargo  bulk  petroleum,  oil,  and  lubrication 
(POL)  in  hundreds  of  barrels 
Heavy  lift  category  code  corresponding  to 
the  heaviest  item  and  the  largest  item 
dimension 

Actual  number  of  detail  records 
Required  number  of  detail  records 
Aggregation  code,  where  1  indicates  that 
the  cargo  category  quantities  represent 
totals  of  the  detail  records 
Date  this  record  was  last  changed 


TPSRFDET 

Edit  Limits 

Stores  the 

imported  TPFDD  SRF  detail  records 

for  non-standard  units 

TPFDD  SRF  Detail 

#  K?  Field  Name 

1 _ 1 - 

Model  Datatype 

i 

( Domain | Lookup ( B | V ( Unit  Meas 

( Description 

OPLAN 

TPSRFCAT 

Operations  plan  number 

Unit  Line  Number 

TPSRFCAT 

Concatenated  force  identifier  or  Unit  Line 
Number  (ULN)  consisting  of  the  force 
requirement  number,  fragmentation  code,  and 
insertion  code 

Cargo  Category  Code 

TPSRFCAT 

JOPES  three  character  cargo  category  code 
defining  the  kind  of  cargo 

Record  Id 

Short >=0 

Record  identifier  number  or  line  number 

Cargo  Category  Code  1 

CCC1 

Yes 

First  position  of  the  JOPES  cargo  category 
code,  defining  the  kind  of  cargo 

Cargo  Category  Code  2 

CCC2 

Yes 

Second  position  of  the  JOPES  cargo  category 
code,  defining  the  air  cargo  type  and  the 
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TPSRFDET 
TPFDD  SRF  Detail 


Edit  Limits  Stores  the  imported  TPFDD  SRF  detail  records  for  non-standard  units 


1 _ 

t  K? 

Field  Name 

Model  Datatype 

Domain (Lookup  B|V  Unit 

_i  _ i _ _ i _ 

7 

Cargo  Category  Code  3 

CCC3 

Yes 

8 

Cargo  Description 

A14 

9 

Length  Inches 

Short >=1 

Yes  In 

10 

Width  Inches 

Short >=1 

Yes  In 

11 

Height  Inches 

Short >=1 

Yes  In 

12 

Area  SqFt 

Double >=0 

Yes  SqFt 

13 

Number  of  Pieces 

Short >=1 

Yes 

14 

Weight  Ston 

Item  Ston 

Yes  Ston 

15 

Volume  Mton 

Double>=0 

Yes  Mton 

16 

Date  Last  Changed 

Date 

Meas  Description 


unit  class 

Third  position  of  the  JOPES  cargo  category 
code,  defining  the  cargo  containerizability 
Equipment  name  or  description 
Cargo  length  in  inches  of  one  piece  of 
equipment  described  by  this  record 
Cargo  width  in  inches  of  one  piece  of 
equipment  described  by  this  record 
Cargo  height  in  inches  of  one  piece  of 
equipment  described  by  this  record 
Cargo  area  in  square  feet  of  one  piece  of 
equipment  described  by  this  record 
Number  of  pieces  of  the  item  of  equipment 
described  by  this  record 

Cargo  weight  in  short  tons  of  one  piece  of 
equipment  described  by  this  record 
Cargo  volume  in  measurement  tons  of  one 
piece  of  equipment  described  by  this  record 
Date  this  record  was  last  changed 


TPSRFID 

TPFDD  SRF  Ident 

Edit  Limits 

Stores  the 

imported  TPFDD  SRF  identifier  records  for  non-standard  units 

#  K?  Field  Name 

1 _ l _ 

^ Model  Datatype 

Domain  1  Lookup  B|V  Unit  Meas  Description 
i  i  i  i 

1  Y  OPLAN 

2  OPLAN  Date 

3  OPLAN  Classification 

4  OPLAN  Identification 

5  Task  Organization 

6  Objective  Area 

7  OPLAN  Change  Number 

8  Operations  Concept 

9  Operations  Concept  More 

10  First  Available  FRN 

11  Last  Available  FRN 

12  Last  Reserved  FRN 

13  Agency  FRN  Ranges 

14  Total  Number  SRF  Records 

15  OPLAN  Owner  UIC 

16  Date  Created 

17  Date  Last  Changed 

18  Force  Select  Counter 

19  OPLAN  TUCHA  Date 


TPID 

A18 

A19 

A40 

A50 

A40 

A2 

A255 

A150 

A3 

A3 

A3 

A200 

Long>=0 

A6 

Date 

Date 

Long>=0 


A18 


Operations  plan  number,  which  should  match 

the  OPLAN  Number  in  the  TPID  table 

Date  assigned  to  the  OPLAN 

Operations  plan  security  classification 

Operations  plan  identification 

Task  organization  for  this  OPLAN 

Primary  objective  area  of  this  OPLAN 

Operations  plan  change  number 

Brief  concept  of  operations  for  this  OPLAN 

Continuation  of  the  concept  of  operations 

for  this  OPLAN 

First  available  force  requirement  number 
(FRN) 

Last  available  force  requirement  number 
(FRN) 

Last  reserved  force  requirement  number 
(FRN) 

Force  requirement  numbers  reserved  for  this 
OPLAN 

Total  number  of  Summary  Reference  File 
(SRF)  records  in  this  TPFDD 
Unit  Identification  Code  (UIC)  of  the  owner 
of  the  data  in  this  OPLAN 
Date  this  record  was  created 
Date  this  record  was  last  changed 
Force  select  counter  which  tracks  the 
number  of  records  created  during  building 
and  maintenance 

TUCHA  date  matching  this  OPLAN  (often  left 
blank,  otherwise  should  match  the  date  in 
the  TUID  table) 


TPUNIT 

TPFDD  Unit 

Edit  Limits 

Stores  the 

imported  TPFDD  standard  force  unit  records 

#  K?  Field  Name 

1 _ 1 _ 

^ Model  Datatype 

Domain | Lookup  B[V  Unit  Meas  ^ Description 

1  Y 

OPLAN 

TPID 

Operations  plan  number 

2  Y 

Unit  Line  Number 

A7 

Concatenated  force  identifier  or  Unit  Line 
Number  (ULN)  consisting  of  the  force 
requirement  number,  fragmentation  code,  and 
insertion  code 

3 

Force  Requirement  Number 

A5 

Yes 

Force  requirement  number,  part  of  the  Unit 
Line  Number 

4 

Force  Fragmentation  Code 

A1 

Fragmentation  code,  part  of  the  Unit  Line 

NiimhPT* 

5 

Force  Insertion  Code 

A1 

Insertion  code,  part  of  the  Unit  Line 

Number 

6 

Providing  Organization 

ORGCODE 

Providing  organization  or  activity  that  is 
responsible  for  providing  the  cargo  or 
personnel  from  this  requirement 

7 

Service  Code 

ORGCODE 

Yes 

JOPES  service  code  or  organization 

8 

Unit  Type  Code 

TUUTC 

Yes 

Unit  type  code,  with  the  first  position 
representing  the  functional  area 

9 

Unit  Type  Function 

UTCFUNCT 

Yes 

Unit  type  code  first  position  which 
represents  the  functional  area  of  the  unit 

10 

Unit  Level  Code 

ULC 

Yes 

Unit  level  code  which  categorizes  the  type 
of  unit  according  to  stratum,  echelon,  or 
control  concentration 

11 

Force  Description 

A31 

Yes 

Force  description 
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TPUNIT 

TPFDD  Unit 

Edit  Limits 

Stores  the 

imported  TPFDD  standard  force  unit  records 

$  K?  Field  Name 
_ 1 _ 

( Model  Datatype 

Domain  |  Lookup  ( B  |  V  ^  Unit  Meas  ^  Description 

12  TPSN  or  Other  Force  Desc 


13  Force  Indicator  Code 


A5 


FIC 


Yes 


Troop  Program  Sequence  Number  (TPSN)  for 
the  Army 

Force  indicator  code  which  defines  whether 
this  unit  movement  data  is  standard  with 
TUCHA  quantities  or  non-standard  with  SRF 


14  Parent  Indicator  Code 


15  Unit  Id  Code 


16  Unit  Name 

17  Unit  Source 

18  Project  Code 

19  Authorized  Personnel 

20  Pax  Needing  Transport 

21  Bulk  Weight  Ston 

22  Bulk  Volume  Mton 

23  Oversize  Weight  Ston 

24  Oversize  Volume  Mton 

25  Outsize  Weight  Ston 

26  Outsize  Volume  Mton 

27  NAT  Weight  Ston 

28  NAT  Volume  Mton 


PIC 

quantities 

Parent  indicator  code  which  indicates 

A6 

whether  the  unit  represents  a  parent,  with 
or  without  subordinate  splits 

Unit  Identification  Code  (UIC)  assigned  as 

A30 

the  actual  unit  to  fill  this  force 
requirement 

Unit  name  assigned  to  fill  this  force 

All 

requirement 

Unit  source  assigned  to  fill  this  force 

A3 

requirement 

Project  code  used  to  identify  special 

Long>=0 

Pax 

projects 

Authorized  wartime  strength  or  personnel 

Long>=0 

Pax 

Number  of  personnel  requiring  non- organic 

Double >=0 

Yes  Ston 

transport  when  this  requirement  moves 

Bulk  weight  in  short  tons 

Double >=0 

Yes  Mton 

Bulk  volume  in  measurement  tons 

Double >=0 

Yes  Ston 

Oversize  weight  in  short  tons 

Double >=0 

Yes  Mton 

Oversize  weight  in  short  tons 

Double>=0 

Yes  Ston 

Outsize  weight  in  short  tons 

Double >=0 

Yes  Mton 

Outsize  volume  in  measurement  tons 

Double>=0 

Yes  Ston 

Non  air  transportable  cargo  weight  in  short 

Double >=0 

Yes  Mton 

tons 

Non  air  transportable  cargo  volume  in 

29  Bulk  POL  Cbbl  Double>=0  Cbbl 


30  Actual  Cargo  Categories  Short>=0 

31  Required  Cargo  Categories  Short>=0 


32 

Standard  Force  Desc  Flag 

A1 

33 

Origin  Geoloc 

GEOLOC 

Yes 

34 

Origin  Country  State 

CNTRYST 

35 

Unit  RLD 

Short +/- 

day 

36 

POE  Geoloc 

GEOLOC 

37 

POE  Country  State 

A2 

38 

POE  ALD 

Short*/ - 

day 

39 

Computed  POD  EDD 

Short*/- 

day 

40 

POE  Preferred  Mode 

MODE  SRC 

41 

POE  Preferred  Source 

M0DE_SRC 

42 

POE  Alt  Geoloc 

GEOLOC 

43 

POE  Alt  Country  State 

A2 

44 

POI  Geoloc 

GEOLOC 

45 

POI  Country  State 

A2 

46 

POI  Preferred  Mode 

M0DE_SRC 

47 

POI  Preferred  Source 

M0DE_SRC 

48 

POI  Days  Delay 

Short >=0 

day 

49 

POI  Delay  Type 

DELTYPE 

50 

POI  Location  Order  Code 

POILOC 

51 

POI  Load  Configuration 

POI  Discharge  Constraint 

LOADCFG 

52 

DISCHCFG 

53 

POD  Geoloc 

GEOLOC 

54 

POD  Country  State 

CNTRYST 

55 

POD  EAD 

Short +/ - 

day 

56 

POD  LAD 

Short*/ - 

day 

57 

POD  Closure  Day 

Short+/- 

day 

58 

POD  Projected  Days  Late 

Short>=0 

day 

59 

POD  Preferred  Mode 

MODE  SRC 

60 

POD  Preferred  Source 

M0DE_SRC 

61 

POD  Load  Configuration 

LOADCFG 

52 

measurement  tons 

Cargo  bulk  petroleum,  oil,  and  lubrication 
(POL)  in  hundreds  of  barrels 
Actual  number  of  cargo  categories 
associated  with  the  requirement 
Required  number  of  cargo  categories 
associated  with  the  requirement 
TUCHA  status  indicator  for  which  a  value  of 
X  indicates  the  force  description  is  not  to 
be  changed  by  the  TUCHA  value 
Origin  geoloc  code 
Origin  country/ state  code 
Unit  ready  to  load  day  (RLD) 

POE  geoloc  code 

POE  country/ state  code 

POE  available  to  load  date  (ALD) 

The  computed  earliest  delivery  day  (EDD) 
the  unit  could  possibly  arrive  at  the  POD 
based  on  the  POE  ALD 

Preferred  mode  of  transport  to  the  POE 

Preferred  organizational  source  of 

transport  to  the  POE 

POE  alternate  geoloc  code 

POE  alternate  country/ state 

Port  of  intermediate  (POI)  location  geoloc 

code 

Intermediate  country/state 
Preferred  mode  of  transport  to  the 
intermediate  location 
Preferred  organizational  source  of 
transport  to  the  intermediate  location 
Days  delay  at  the  intermediate  location 
Intermediate  delay  type,  with  T  indicating 
entire  force  delay  at  POI  and  F  indicating 
incremental  portions  of  the  forces 
Code  describing  the  location  of  the 
intermediate  port  relative  to  the  POE  and 
POD 

Intermediate  load  configuration 

Intermediate  discharge  constraint 

POD  geoloc  code 

POD  country/state  code 

POD  earliest  arrival  date  (EAD) 

Latest  arrival  date  (LAD)  by  which  the 
requirement  must  arrive  and  complete 
unloading  at  the  POD 

POD  feasible  arrival  date  (FAD)  by  which 
the  requirement  completes  unloading  at  the 
POD 

Projected  days  late  at  the  POD 
Preferred  mode  of  transport  to  the  POD 
Preferred  organizational  source  of 
transport  to  the  POD 
POD  load  configuration 
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TPUNIT 
TPFDD  Unit 


K?  Field  Name 


Edit  Limits  I  Stores  the  imported  TPFDD  standard  force  unit  records 


Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 


62  POD  Discharge  Constraint 

63  POD  Alt  Geoloc 

64  POD  Alt  Country  State 

65  POD  Arr  Priority  Sequence 

66  Priority  Add  On  Sequence 

67  Dest  Geoloc 

68  Dest  Country  State 

69  Dest  RDD 

70  Dest  Preferred  Mode 

71  Dest  Preferred  Source 

72  Dest  Load  Configuration 

73  Dest  Discharge  Constraint 

74  Sea  Support  Geoloc 

75  Sea  Support  Country  State 

76  Air  Support  Geoloc 

77  Air  Support  Country  State 

78  POL  Supply  Geoloc 

79  POL  Supply  Country  State 

80  Ammo  Supply  Geoloc 

81  Ammo  Supply  Country  State 

82  FRG  Force  Select  Number 

83  Date  Created 

84  Date  Last  Changed 

85  Critical  Employment  Flag 

86  CINC  RDD 


DISCHCFG 

GEOLOC 

A2 

Short >=0 


GEOLOC 
CNTRYST 
Short +/- 


MODE_SRC 

MODE_SRC 

LOADCFG 

DISCHCFG 

GEOLOC 

A2 

GEOLOC 

A2 

GEOLOC 

A2 

GEOLOC 

A2 

Long>=0 


86  CINC  RDD  Short +/-  day  Required  delivery  date  of  the  CINC 

destination 

87  Gaining  Command  Code  A5 _ Gaining  command  code _ 

TRANPSRC  Edit  Limits  I  Lists  the  JOPES  transport  source  providing  organization  codes  (MSC,  MTMC,  etc.) 


POD  discharge  constraints 

POD  alternate  geoloc  code 

POD  alternate  country/state 

Desired  arrival  priority  sequence  (001-999) 

for  arrival  at  the  POD 

Priority  add-on  sequence  to  insert  a  unit 
into  the  desired  arrival  sequence 
Yes  Destination  geoloc  code 

Destination  count ry/s tat e  code 
Yes  day  Required  delivery  day  (RDD)  by  which  the 

requirement  must  arrive  and  complete 
unloading  at  the  destination 
Preferred  mode  of  transport  to  the 
destination 

Preferred  organizational  source  of 
transport  to  the  destination 
Destination  load  configuration 
Destination  discharge  constraint 
Desired  geoloc  for  delivery  of  nonunit 
general  cargo  by  sealift 
Desired  country/state  for  delivery  of 
nonunit  general  cargo  by  sealift 
Desired  geoloc  for  delivery  of  nonunit 
general  cargo  by  airlift 
Desired  country/state  for  delivery  of 
nonunit  general  cargo  by  airlift 
Desired  geoloc  for  delivery  of  nonunit  POL 
Desired  country/state  for  delivery  of 
nonunit  POL 

Desired  geoloc  for  delivery  of  nonunit 
ammunition 

Desired  country/state  for  delivery  of 
nonunit  ammunition 

Unique  sequence  number  assigned  to  each 
force  record 

Date  this  record  was  created 
Date  this  record  was  last  changed 
Critical  employment  indicator  flag  which  is 
non-blank  when  the  force  is  essential  to 
the  mission 

day  Required  delivery  date  of  the  CINC  at  the 

destination 
Gaining  command  code 


TRANPSRC  Edit 

JOPES  Tmsprt  Source 


#  K?  Field  Name 

i  i 


1  Y  Transport  Source  Code 

2  Transport  Source 

3  Description 


Model  Datatype 


Domain  I  Lookup  B|V  Unit  Meas  Description 
j _ _ _ _ l _ i _ 


Al  Transport at: 

organization 

A15  Transportat: 

organization 

A100  Description 


Transportation  source  providing 
organization  code 
Transportation  source  providing 
organization  short  name 

Description  of  the  transportation  source 
providing  organization 


TRANSLAT 

Edit  Limits 

Translation  Table 

#  K?  Field  Name 


1  Y  Translation  Name 

2  Y  Input  Data 

3  Translated  Data 


TUCAT 

Edit  Limits 

TUCHA  F2  Category 

#  K?  Field  Name 

i  i 


1  Y  Unit  Type  Code 

2  Y  Cargo  Category  Code 

3  Unit  Type  Function 

4  Cargo  Category  Code  1 

5  Cargo  Category  Code  2 

6  Cargo  Category  Code  3 

7  Security  Classification 


mappings  for  importing  data  from  external  databases 


Model  Datatype  Domain | Lookup  BlV^Unit  Meas  description _ 


A20  Name  of  translation  (reference  Import 

table) 

A25  Spec  for  input  data 

A25  Spec  for  translated  data 


Edit  Limits  Stores  the  imported  TUCHA  F2  cargo  category  quantities  for  standard  unit  types 


Model  Datatype  ^oma in | Lookup (B|V| Unit  Meas  ^ Description 


TUUTC  Unit  type  ci 


CCC 

UTCFUNCT 

CCC1 

CCC2 

CCC3 

CLASSIFC 
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Unit  type  code,  with  the  first  position 
representing  the  functional  area 
JOPES  three -character  cargo  category  code 
describing  cargo  characteristics 
Unit  type  code  first  position  which 
represents  the  functional  area  of  the  unit 
First  position  of  the  JOPES  cargo  category 
code,  defining  the  kind  of  cargo 
Second  position  of  the  JOPES  cargo  category 
code,  defining  the  air  cargo  type  and  the 
unit  class 

Third  position  of  the  JOPES  cargo  category 
code,  defining  the  cargo  containerizability 
Security  classification  for  this  record 


Directory  Type :  Tpf dd 


TUCAT 

TUCHA  F2  Category 

Edit 

Limits 

Stores  the 

imported  TUCHA  F2  cargo  category  quantities  for  standard  unit  types 

#  K?  Field  Name 

Model  Datatype 

f Domain | Lookup ( B | V  ^  Unit  Meas 

Description 

8  Heavy  Lift  Code 

9  Is  Aggregated  Flag 

10  Area  SqFt 

11  Weight  St on 

12  Volume  Mton 

13  Bulk  POL  Cbbl 

14  Required  Detail  Records 

15  Actual  Detail  Records 

HEAVLIFT  Yes 

A1 

Double>=0  Yes  SqFt 

Double>=0  Yes  Ston 

Double>»0  Yes  Mton 

Double >=0  Cbbl 

Short >=0 

Short >=0 

Heavy  lift  category  code  corresponding  to 
the  heaviest  item  and  the  largest  item 
dimension 

F2  aggregation  code,  where  1  indicates  that 
the  F2  cargo  category  quantities  represent 
totals  of  the  F3  detail  records 

Cargo  square  feet 

Cargo  weight  in  short  tons 

Cargo  cube  measurement  tons 

Cargo  bulk  petroleum,  oil,  and  lubrication 
(POL)  in  hundreds  of  barrels 

Required  number  of  F3  detail  records 

Actual  number  of  F3  detail  records 

TUDATE 

TUCHA  Date 

Edit 

Limits 

Stores  the 

imported  TUCHA  date 

#  K?  Field  Name 

i 

Model  Datatype 

Domain  1  Lookup  B|V  Unit 
i  _  i  i  _  . 

Meas 

Description 

1  y  TUCHA  Date 

Date 

TUCHA  date,  which  is  the  date  of  last 
update 

TUDET 

TUCHA  F3  Detail 

Edit 

Limits 

Stores  the 
types 

imported  TUCHA  F3  detail  cargo  quantities  and  dimensions  for  standard  unit 

#  K?  Field  Name 
_ 1 _ 

( Model  Datatype 

Domain | Lookup  B|V  Unit 

i  i  i 

Meas 

Description 

1  Y  Unit  Type  Code 

2  Y  Cargo  Category  Code 

3  Y  Record  Id 

TUCAT 

TUCAT 

Short >=0 

Unit  type  code,  with  the  first  position 
representing  the  functional  area 

JOPES  three  character  cargo  category  code 
defining  the  kind  of  cargo 

Record  identifier  number  or  line  number 

4  Unit  Type  Function 

UTCFUNCT 

Yes 

Unit  type  code  first  position  which 
represents  the  functional  area  of  the  unit 

5  Cargo  Category  Code 

1 

CCC1 

Yes 

First  position  of  the  JOPES  cargo  category 
code,  defining  the  kind  of  cargo 

6  Cargo  Category  Code 

2 

CCC2 

Yes 

Second  position  of  the  JOPES  cargo  category 
code,  defining  the  air  cargo  type  and  the 
unit  class 

7  Cargo  Category  Code 

3 

CCC3 

Yes 

Third  position  of  the  JOPES  cargo  category 
code,  defining  the  cargo  containerizability 

8  Security  Classification 

9  Cargo  Description 

CLASSIFC 

A14 

Security  classification  for  this  record 
Equipment  name  or  description 

10  Length  Inches 

Short >=1 

Yes  In 

Cargo  length  in  inches  of  one  piece  of 
equipment  described  by  this  record 

11  Width  Inches 

Short >=1 

Yes  In 

Cargo  width  in  inches  of  one  piece  of 
equipment  described  by  this  record 

12  Height  Inches 

Short >=1 

Yes  In 

Cargo  height  in  inches  of  one  piece  of 
equipment  described  by  this  record 

13  Area  SqFt 

Short>=0 

Yes  SqFt 

Cargo  area  in  square  feet  of  one  piece  of 
equipment  described  by  this  record 

14  Number  of  Pieces 

Short >*1 

Yes 

Number  of  pieces  of  the  item  of  equipment 
described  by  this  record 

15  Weight  Ston 

Item  Ston 

Yes  Ston 

Cargo  weight  in  short  tons  of  one  piece  of 
equipment  described  by  this  record 

16  Volume  Mton 

Double >=0 

Yes  Mton 

Cargo  volume  in  measurement  tons  of  one 
piece  of  equipment  described  by  this  record 

TUOLDUTC 

TUCHA  AB  Total 

Edit  Limits 

Stores  the  imported  TUCHA  AB  records  containing  updated  UTC  status,  often  cancelled 

#  K?  Field  Name 

i  i 

Model  Datatype  Domain | Lookup  BjV^Unit  Meas  ^ Description 

1 

Y  Unit  Type  Code 

A5 

Unit  type  code  having  a  status  change 
(usually  being  cancelled) ,  with  the  first 
position  representing  the  functional  area 

2 

Unit  Type  Function 

UTCFUNCT 

Yes 

Unit  type  code  first  position  which 
represents  the  functional  area  of  the  unit 

3 

Unit  Level  Code 

ULC 

Unit  level  code  which  categorizes  the  type 
of  unit  according  to  stratum,  echelon,  or 
control  concentration 

4 

Deployment  Indicator  Code 

DEPLOY I C 

JOPES  deployment  indicator  code  which 
characterizes  deployability 

5 

Service  Code 

ORGCODE 

Yes 

JOPES  service  code  or  organization 

6 

Security  Classification 

CLASSIFC 

Security  classification  for  this  record 

7 

Unit  Type  Short  Name 

A15 

Yes 

Unit  type  short  name 

8 

Unit  Type  Status 

UNITSTAT 

Yes 

Unit  type  status  code,  where  A  indicates 
active,  C  indicates  cancelled 

9 

Unit  Type  Name 

A55 

Yes 

Unit  type  name 

10 

Originator  Unit  Id 

A6 

Originator's  unit  identification  code  (UIC) 

11 

Date  Created 

Date 

Date  this  record  was  created 

12 

Date  Last  Changed 

Date 

Date  this  record  was  last  changed 

13 

Authorized  Personnel 

Long>=0 

Pax 

Authorized  wartime  strength  for  personnel 

14 

Date  Cancelled 

Date 

Date  this  record  was  cancelled 

15 

Reference  Document 

A19 

Reference  document  that  authorizes  the  type 
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TUOLDUTC 
TUCHA  AB  Total 


Edit  Limits  Stores  the  imported  TUCHA  AB  records  containing  updated  UTC  status,  often  cancelled 


#  K?  Field  Name 


Model  Datatype  Domain | Lookup  B|V  Unit  Meas  Description 


16  UTC  Replaced 

TUUTC  Edit  Limits 

TUCHA  UTCs  and  Air 


A5 


organization  or  contains  its 
characteristics 
Replacement  unit  type  code 


Stores  the  imported  TUCHA  ABF1  UTC  records,  including  total  air  cargo  type  quantities 


1 _ 

#  K? 

i 

Field  Name  Model  Datatype 

Domain | Lookup ( B | V ^ Unit 

1  Y 

Unit  Type  Code 

A5 

2 

Unit  Type  Function 

UTCFUNCT 

Yes 

3 

Unit  Level  Code 

ULC 

Yes 

4 

Deployment  Indicator  Code 

DEPLOYIC 

Yes 

5 

Service  Code 

ORGCODE 

Yes 

6 

Security  Classification 

CLASSIFC 

7 

Unit  Type  Short  Name 

A15 

Yes 

8 

Record  Completion  Code 

RECCODE 

9 

Unit  Type  Status 

UNITSTAT 

10 

FI  Security  Classif 

CLASSIFC 

11 

Unit  Type  Name 

A55 

Yes 

12 

Originator  Unit  Id 

A6 

13 

Date  Created 

Date 

14 

Date  Last  Changed 

Date 

15 

Authorized  Personnel 

Long>=0 

Pax 

16 

Pax  Needing  Transport 

Long>=0 

Pax 

17 

Required  Cargo  Categories 

Short>=0 

18 

Actual  Cargo  Categories 

Short >=0 

19 

Reference  Document 

A19 

20 

UTC  Replaced 

AS 

21 

Bulk  Weight  St  on 

Double >-0 

Yes  Ston 

22 

Bulk  Volume  Mton 

Double>=0 

Yes  Mton 

23 

Oversize  Weight  Ston 

Double>=0 

Yes  Ston 

24 

Oversize  Volume  Mton 

Double>=0 

Yes  Mton 

25 

Outsize  Weight  Ston 

Double >=0 

Yes  Ston 

26 

Outsize  Volume  Mton 

Double >=0 

Yes  Mton 

27 

NAT  Weight  Ston 

Double >=0 

Yes  Ston 

28 

NAT  Volume  Mton 

Double>-0 

Yes  Mton 

29 

Bulk  POL  Cbbl 

Double >=0 

Cbbl 

Description 


Unit  type  code,  with  the  first  position 

representing  the  functional  area 

Unit  type  code  first  position  which 

represents  the  functional  area  of  the  unit 

Unit  level  code  which  categorizes  the  type 

of  unit  according  to  stratum,  echelon,  or 

control  concentration 

JOPES  deployment  indicator  code  which 

characterizes  deployability 

JOPES  service  code  or  organization 

Security  classification  for  this  record 

Unit  type  short  name 

Record  completion  indicator  code 

Unit  type  status  code,  where  A  indicates 

active,  C  indicates  cancelled 

Security  classification 

Unit  type  name 

Originator's  unit  identification  code  (UIC) 

Date  this  record  was  created 

Date  this  record  was  last  changed 

Authorized  wartime  strength  for  personnel 

Pax/non- organic  transport 

Required  cargo  categories 

Actual  cargo  categories 

Reference  document  that  authorizes  the  type 

organization  or  contains  its 

characteristics 

Replacement  unit  type  code 

Bulk  weight  in  short  tons 

Bulk  volume  in  measurement  tons 

Oversize  weight  in  short  tons 

Oversize  weight  in  short  tons 

Outsize  weight  in  short  tons 

Outsize  volume  in  measurement  tons 

Non  air  transportable  cargo  weight  in  short 

tons 

Non  air  transportable  cargo  volume  in 
measurement  tons 

Cargo  bulk  petroleum,  oil,  and  lubrication 
(POL)  in  hundreds  of  barrels 


ULC 

Edit  Limits 

Lists  the  JOPES  unit  level  codes 

UNIT  Level  Code 

Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 


-i - 1 - 

1  Y  Unit  Level  Code 

_ _ i - 1 - 1 - - 

A3 

Unit  level  code  which  categorizes  the  type 

of  unit  according  to  stratum,  echelon,  or 

control  concentration 

2  Description 

A35 

Unit  level  code  description 

UNITCLAS  Edit  Limits 

JOPES  Unit  Class 

Lists  the  JOPES  unit  classifications 

(Unit  Equip,  Acc  Supply,  Organic) 

#  K?  Field  Name 


Model  Datatype 


Domain | Lookup t B ] V ^ Unit  Meas  description 


1  Y  Unit  Class  Label 


Unit  Classification 


A2 


A15 


Unit  equipment  classification  short  label 
(Ue, Ac,Nu)  for  the  second  position  of  the 
cargo  category  code 

Unit  equipment  classification  (Unit  Equip, 
Acc  Supply,  Non  Unit) 


UNITSTAT 

JOPES  Unit  Status 

Edit  Limits 

Lists  the  JOPES 

unit  status  codes  (active,  canceled) 

#  K?  Field  Name 

i _ i 

Model  Datatype 

i 

Domain  1  Lookup  B|V  Unit  Meas  Description 

i  *  i  i  t 

1  Y  Unit  Status  Code 

2  Unit  Status 


A1 


A10 


Unit  status  code,  where  A  indicates  active, 
C  indicates  cancelled 
JOPES  unit  status  description 
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UPDATEDT 

Dictionary  Update 


Edit  Limits 
Hide 


Stores  the  latest  update  date  for  table  structures  in  this  directory 


**  K?  Field  Name 


-L- 

1  Y  Dictionary  Update  Date 


^ Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 


Date 


Latest  date  for  updating  the  dictionary 
table  structures  using  the  UPDATE 
specifications 


UTCFUNCT 

JOPES  UTC  Function 

Edit 

Limits 

Lists  the  JOPES  Unit  Type  Code  functional  area  which  is  the  first  position  of  the  Unit 
Type  Code 

#  K?  Field  Name 

Model  Datatype 

Domain | Lookup  ^ B | V  ^ Unit  Meas 

Description 

1  Y  UTC  Functional 

Code 

A1 

Unit  Type  Code  (UTC)  first  position 

functional  area  code 

2  Unit  Functional  Area 

A18 

Unit  type  functional  area/  also  used  as  the 

default  Major  Unit  aggregation  in  AGGMAJUN 

3  Description 

ABO 

Unit  type  functional  area  description 

UTCSUBST 

Edit 

Limits 

Lists  the  Unit  Type  Code  substitutions  for  standard  units  that  have  no  match  in  the 

UTC  Substitution 

TUCHA  data 

. J 

#  K?  Field  Name 

Model  Datatype 

Domain | Lookup  Blv  Unit  Meas 
i  i  i 

Description 

1  Y  OPLAN 

TPUNIT 

Operations  plan  number 

2  Y  Unit  Line  Number 

TPUNIT 

Concatenated  force  identifier  or  Unit  Line 

Number  (ULN)  which  has  an  unmatched  Unit 

Type  Code  (UTC) 

3  Substitute  Unit  Type  Code 

TUUTC 

Substitute  Unit  Type  Code  which  does  have  a 

match  in  the  TUCHA  TUUTC  table 

XREQNODE 

Edit 

Limits 

Lists  aggregated  required  intermediate  POE  or  POD  nodes  or  ports  for  export  to  scenario 

Export  Req  Node 

Output 

directories 

1 

#  K?  Field  Name 
_ 1 - 

Model  Datatype 
_ 1 - 

Domain  1  Lookup  B|V  Unit  Meas 
i  i  i 

Description 

i 

1  Y  Requirement  Id 

2  Y  Cargo  Class 

3  Y  LAD 

4  EAD 

5  Required  Node 

6  Required  Mode  to  Node 

7  Required  Config  to  Node 

8  Stage  Name 

9  Description 


XREQUIRE 

Movement  requirement  identifier  with 
intermediate  ports  or  staging 

A15 

Cargo  class  for  which  the  required  node 
applies 

DayToHr 

day 

(hr) 

Latest  arrival  day  at  this  required  port 
node  (the  LAD  is  used  to  determine  the 
order  in  which  required  nodes  are  visited) 

DayToHr 

day 

(hr) 

Earliest  arrival  day  at  this  required  port 
node,  if  any 

A15 

Yes 

Required  intermediate  POE/POD  node  or  port 
for  this  movement  requirement 

A15 

Required  transport  mode  specified  for 
delivery  to  the  intermediate  node,  if  any 
(blank  permits  the  use  of  any  mode  for 
delivery) 

A15 

Required  configuration  specified  for 
delivery  to  the  intermediate  node,  if  any 

(blank  permits  the  use  of  any 
configuration) 

A15 

Staging  deployment  name  if  multiple 
requirements  are  staged  together  at  this 
node  (the  STAGE  record  must  have  the  same 
node  as  in  REQNODE) 

A50 

Description  of  this  intermediate  node,  e.g 
consolidation,  container  stuffing,  mode 
change,  re -configuration,  combat  loading. 

XREQQUAN 

Edit  Limits 

Provides  aggregated  quantity  data  for  each  movement  requirement  and  cargo  category  for 

Export  Req  Quantity 

Output 

export  to  scenario  directories 

#  K?  Field  Name 

I _ 1 _ 

( Model  Datatype  ( Domain | Lookup ( B | V ^ Unit  Meas  Description 

1  Y  Requirement  Id 

2  Y  Cargo  Category 

3  Y  Cargo  Measure 

4  Quantity 


XREQUIRE 

A15 

A15 

reqqn 


Yes  Q 


Requirement  identifier  for  the  cargo 
Cargo  category  which  describes  the  kind  of 
cargo  being  transported 
Dimensional  measure  for  this  requirement 
and  cargo  category 

Requirement  category  quantity  or  dimension 
in  this  unit  of  measure 


XREQUIRE 

Export  Requirement 


Edit  Limits 
Output 


Provides  aggregated  information  about  each  movement  requirement  or  package  for  export  to 
scenario  directories 


t  K? 

Field  Name 

i 

} Model  Datatype 

( Domain | Lookup ( B 1 v ( Unit  Meas 

( Description 

1  Y 

Requirement  Id 

A15 

Movement  requirement  or  package  id 

2 

Major  Unit 

A20 

Yes 

Major  unit  associated  with  this  movement 
requirement 

3 

Origin 

A15 

Yes 

Starting  origin  of  the  requirement 

4 

Destination 

A15 

Yes 

Final  destination  of  the  requirement 

5 

RLD 

DayToHr 

day  (hr) 

Ready  to  load  day  or  earliest  day  the 
requirement  is  available  at  its  origin 
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XREQUIRE 

Export  Requirement 

Edit  Limits 
Output 

Provides  aggregated  information 
scenario  directories 

about 

each  movement  requirement  or  package  for  export  to 

%  K?  ^  Field  Name 

Model  Datatype  Domain | Lookup  B|V  Unit 

i  i  i _ _ i _ 

Meas 

Description 

6  RDD 

DayToHr 

day 

(hr) 

Required  delivery  day  of  the  packaged 
requirement  at  its  destination  including 
time  for  assembly 

7  EDD 

DayToHr 

day 

(hr) 

Earliest  allowed  delivery  day  of  the 
requirement  at  its  destination  prior  to 
assembly 

8  Computed  Closure  Day 

DayToHr 

day 

(hr) 

Closure  day  for  the  requirement  based  on 
the  closure  minimum  %  requirement  specified 

in  the  REQTYPE  table 


9  Priority  Order 


1,99  Relative  priority  order  for  this 

requirement  as  a  secondary  sort  after  the 
Target  Lift  Date  (one  means  first  priority 
in  assigning  lift  assets,  blank  defaults  to 
the  priority  order  of  the  requirement  type) 
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CANDIDAT 

Candidate 

Edit  Limits 
Model  Only 

Lists  candidate  vehicle  assignments  sorted 
cost/benefit  ratio 

into  heap  order  according  to  increasing 

#  K?  Field  Name 
_ 1 _ 

( Model  Datatype  ( Domain | Lookup  BjV^Unit  Meas 

Description 

1  Y  Candidate 

2 
3 


heapcnd 

cbratio 


Record#  Vehic 

CANDIDAT 

Long>=0 


Heap  sort  position  or  priority  sequence 
order  (first  index  is  least) 

Heap  position  for  this  vehicle  or  cargo 
scheduling  candidate 
Vehicle  cost /benefit  ratio  for  cargo 
assignment,  used  to  sort  the  heap 


CMEASFUL 

Class  Measure  Full 


Edit  Limits 
Model  Only 


Stores  in  the  model  the  matching  class  measure  record  in  CLASMEAS,  if  any,  for  every 
full  combination  of  cargo  class  and  measure 


#  K?  Field  Name 


L_ 


Model  Datatype 


Domain | Lookup  B|v  Unit  Meas 


Description 


1  Y  Cargo  Class 

2  Y  Measure 

3 


clasmeas 


CARGCLAS 

MEASURE 

CLASMEAS 


Cargo  class 
Measure 

Matching  cargo  class/measure  record  in 
CLASMEAS,  if  any,  for  this  cargo  class  and 
measure  combination 


CONVTHTR 
Convoy  Theater 


Edit  Limits 
Model  Only 


Lists  which  pairs  of  theaters  have  convoys 


#  K?  Field  Name 


L_ 


Model  Datatype 


Domain  I  Lookup  BlV  Unit  Meas 
- I -  1  —  I _ 


Description 


1  Y  From  Theater 

2  Y  To  Theater 

3  Has  Convoy? 


hascnvy 


THEATER 

THEATER 

Boolean 


From  theater 
To  theater 

Flag  that  is  1  if  a  convoy  record  travels 
between  the  theaters,  0  otherwise 


CRGVTYPE 

CARGOxVehicle  Types 


Edit  Limits 
Model  Only 


Stores  the  first  matching  STOWPEN  record  in  the  model  for  feasible  combinations  of  cargo 
type  and  vehicle  type 


#  K?  Field  Name 


Model  Datatype 


t Domain | Lookup  B | V  ^ Unit  Meas 


Description 


1  Y  Cargo  Type 

2  Y  Vehicle  Type 

3 


crgvstowpen 


CARGTYPE 


VEHTYPE 

STOWPEN 


Cargo  type  which  describes  the  kind  of 
cargo  being  transported 
Vehicle  Type 

First  feasible  Stowage  Penalty  record  for 
this  cargo  type  and  vehicle  type,  or  zero 
if  the  combination  is  infeasible 


FACCAPHR  Edit  Limits 

Facility  Capacity  Hr  Model  Only 


Stores  the  remaining  available  capacity  for  each  facility,  capacity  measure,  and  hour  of 
operation  (rebuilt  each  simulation  day) 


#  K?  Field  Name 


L. 


Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 


1  Y  Facility  Node 

2  Y  Facility  Name 

3  Y  Facility  Capacity  Measure 

4  Y  Operating  Hour 

5  Remaining  Hourly  Capacity  faccaprem 


Record#  Vehic  Node  with  capacity  constraints 

FACCAP  Facility  with  capacity  constraints 

FACCAP  Cargo  storage  or  throughput  capacity 

measure  for  this  facility  and/or  node 
0,24  hr  Operating  hour  at  the  facility  or  node 

Long>=0  Q  Remaining  storage  or  throughput  capacity 

for  this  measure  and  facility  type  for  a 
single  hour  of  operation 


FACEVENT  Edit  Limits 

Facility  Capac  Event  Model  Only 


Stores  all  facility  capacity  events  for  the  FACILITY  table  with  capacities  from  the 
FACCAP  table 


#  K?  Field  Name 


I— 


Model  Datatype 


t Domain [ Lookup  t  B 1 V  ^  Unit  Meas  description 


1  Y  Capacity  Event  Number 

2  Capacity  Event  Time 

3 

4 


capeventime 

firstcapremain 

nextcapevent 


Record#  BigSt  Yes 
Long>=0  Yes  Hours 

FACREM 

FACEVENT 


Facility  capacity  event  number 

The  time  at  which  the  facility  capacity 

event  occurs 

The  first  matching  record  for  multiple 
matching  capacity  remaining  measures 
List  next  pointer  for  the  list  of  capacity 
events 


FACREM 

Capacity  Remaining 


Edit  Limits 
Model  Only 


Stores  remaining  capacities  for  multiple  measures  associated  with  each  facility  capacity 
event 


#  K?  Field  Name 
\ _ l _ 


Model  Datatype 


| Domain | Lookup  <  B | V ^ Unit  Meas  Description 


1  Y  Capacity  Remaining  Number 

2  Capacity  Remaining  capremain 


Record#  BigSt  Yes 
Long>=0  Q 


Record  number  for  the  capacity  remaining 
quantity 

Facility  event  capacity  remaining  for  a 
particular  measure 


FROMROUT 
From  Node  Route 


Edit  Limits 
Model  Only 


Full  table  for  routelists  with  key  fields  of  From  Node,  Route  Type,  and  Is  Empty 


#  K?  Field  Name 
I _ 1 _ 


Model  Datatype 


^  Domain [ Lookup  B | V  Unit  Meas 


Description 


1  Y  From  Node 

2  Y  Route  Type 

3  Y  Vehcicle  is  Empty 


NODE 

ROUTTYPE 

Boolean 


From  node  for  storing  route  list  pointers 
Route  type  for  storing  route  list  pointers 
Empty  vehicle  indicator  for  distinguishing 
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FROMROUT 

From  Node  Route 

Edit  Limits 
Model  Only 

Full  table 

for  routelists  with  key  fields  of 

From  Node,  Route  Type, 

and  Is  Empty 

#  K?  t Field  Name 

Modf 

*1  Datatype 

Domain | Lookup  ^  B | V ( Unit  Meas 

Description 

L - 

4 

1 is trout e 

ROUTE 

refueling  route  types 
List  pointer  to  a  list 
this  type  and  fromnode 

of  tonode  routes  of 

LNKEVENT 

Node  Link  Event 

Edit  Limits 
Model  Only 

Stores  the 

usage  events  at  links  with  constrained  capacity 

#  K?  Field  Name 

1 _ 1 - 

Model  Datatype 

i  .  . 

Domain] Lookup (B|V(Unit  Meas 

Description 

1  Y  Link  Event  Number 

2  Link  Event  Time 

3 


lnke vent_t ime 
first Inkcapremain 

nextlnkevent 


Record#  BigSt 

Long>=0 

LNKREM 

LNKEVENT 


Time  at  which  the  link  event  occurs 
The  first  in  the  group  of  remaining 
capacities  for  this  link  event 
The  next  link  event  in  the  list  of  link 
events 


LNKREM  Edit  Limits 

Link  Capacity  Remain  Model  Only 


Stores  the  remaining  capacities  for  a  link  events  in  the  various  units  of  measure 


#  K?  Field  Name 
I _ I - 


Model  Datatype 
_l - 


Domain  I  Lookup  B|V  Unit  Meas  Description 
J _ _ _  I  I - 1 - — 


1  Y  Link  Remaining  Number 

2  Link  Capacity  Remaining  Xnkremain 


Record#  BigSt 
Long>-0 


Record  number  for  indexing  link  capacity 
remaining  amounts 

The  amount  of  link  capacity  remaining  for 
some  link  event 


NODCAPHR 

Node  Capacity  Hr 


Edit  Limits 
Model  Only 


Stores  the  remaining  available  capacity  for  each  node,  capacity  measure,  and  hour  of 
operation  (rebuilt  each  simulation  day) 


#  K?  Field  Name 
J - 1 - 


Model  Datatype 


Domain | Lookup  B|v  Unit  Meas  Description 


1  Y  Node  Name 

2  Y  Node  Capacity  Measure 

3  Y  Operating  Hour 

4  Remaining  Hourly  Capacity  nodecaprem 


Record#  Vehic  Node  name  with  loading  or  unloading 

facilities 

NODECAP  Unit  of  measure  for  overall  cargo  handling 

capacity  at  the  node 

0,24  hr  Operating  hour  at  the  node 

Long>=0  Q  Remaining  throughput  or  storage  for  this 

measure  and  node  for  a  single  hour  of 
operation 


NODEVENT 

Node  Capacity  Event 

Edit  Limits 
Model  Only 

Stores  all 
table 

node  capacity  events  for  the  NODE 

table  with  capacities  from  the  NODECAP 

#  K?  Field  Name 
l _ 1 - 

Model  Datatype 

i 

Domain | Lookup ( B | V ( Unit  Meas 

Description 

1  Y  Node  Event  Number 

2  Node  Event  Time 

3 


nodeventime 

firstnodremain 

nextnodevent 


Record#  BigSt  Yes 
Long>=0  Yes  Hours 

NODREM 

NODEVENT 


Node  capacity  event  number 
The  time  the  node  capacity  event  occurs 
The  first  matching  remaining  capacity 
record  for  multiple  measures 
List  next  pointer  for  the  list  of  node 
capacity  events 


NODREM 

Node  Cap  Remaining 

Edit  Limits 
Model  Only 

Stores  remaining  capacities  for  multiple  measures  associated  with  each  node 
event 

capacity 

#  K?  Field  Name 

Model  Datatype 

Domain  1  Lookup  B|V  Unit  Meas 
t  I  i 

Description 

1  Y  Node  Capacity  Rem  Id 

2  Node  Capacity  Remaining  nodr  etna  in 

Record#  BigSt  Yes 

Long>«0  Q 

Node  capacity  remaining  record  number 

The  node  remaining  capacity  for  a  given 
unit  of  measure 

NODSTATE 

Node  State 

Edit  Limits 
Model  Only 

Defines  multiple  dynamic  programming  states 
routing  with  refueling 

at  each  node,  used  in  mode  planning  and 

#  K?  Field  Name 

1 _ l - 

( Model  Datatype 

Domain ] Lookup  B|V  Unit  Meas 
_ l _ ! _ - 

Description 

_J - 

1  Y  State  Node 


2  Y  State  Fleet 

3  Y  State  Configuration 

4 

5 


NODE 

PLANFLT 

CARGCONF 

stpred 

stpredlink 

NODSTATE 
Short >=0 

stcost 

Long>-0 

heapmodeplan 

NODSTATE 

onmodeplanheap 

Short >=0 

Node  state  number  generated  for 
port /mode /fleet/conf igurat ion  planning 
using  dynamic  programming 
Transport  fleet  associated  with  this  state 
Cargo  configuration  associated  with  this 
state 

Predecessor  state  in  reaching  this  state 
The  link  used  to  travel  from  the  predessor 
state  to  the  this  state  (in  some  cases  this 
is  a  notional  " convoy"  link  >NLINK) 

Current  cumulative  cost  of  the  state, 
including  its  lower  bound  to  the 
destination 

Candidate  queue  of  preferred  states  for 
processing  in  the  state  optimization 
algorithm 

Status  indicator  and  pivot  count  for 
candidate  states  on  the  preferred/ deferred 
queues  in  the  state  optimization  algorithm 
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NODSTATE 
Node  State 


#  K?  Field  Name 


Edit  Limits  Defines  multiple  dynamic  programming  states  at  each  node,  used  in  mode  planning  and 
Model  Only  routing  with  refueling _ _ __ _ 


Model  Datatype  Domain | Lookup  B|V  Unit  Meas  Description  _ 


Model  Datatype 
st time 

state  vehfleet 


state_poestate 

statejpfdelay 


Short >=0 
VEHFLEET 


Absolute  time  assigned  to  the  state 
The  record  in  the  VehFleet  table,  if  any, 
which  was  used  to  move  the  cargo  to  this 
state 

The  nodstate  record  representing  the  poe 
for  this  vehfleet  movement 
The  delay  due  to  planning  fleet  capacity 
due  to  this  transition 


PFLEVENT 
Fleet  Event 


#  K?  Field  Name 


Edit  Limits  Lists  the  fleet  capacity  events 
Model  Only 


1  Y  Fleet  Event  Number 

2  Fleet  Event  Time 

3 


Model  Datatype 


fl  eventime 
firstfleetrem 


nextf  levent 


Domain | Lookup  B|V  Unit  Meas  Description 


Record#  BigSt 

Long>=0 

PLNFLTRM 


A  number  to  provide  a  key  for  this  table 

The  time  the  event  occurs 

First  in  the  group  of  fleett  capacity 

remaining  records  for  this  event 

Next  pointer  for  the  list  of  fleet  events 


PLNFLTRM  Edit  Limits  Lists  the  capacities  remaining  for  associated  fleet  events 

Plan  Fleet  Cap  Rem  Model  Only 


#  K?  Field  Name 


Model  Datatype 


Domain  I  Lookup  B|V  Unit  Meas  Description 


1  Y  Fleet  Remaining  Number 

2  Fleet  Capacity  Remaining  fleet caprem 


Record#  BigSt 
Long>=0 


Fleet  capacity  remaining  record  number 
The  amount  of  fleet  capacity  remaining 


POEFAC 

POE  Plan  Facility 


#  K?  Field  Name 


1  Y  POE  Fleet 

2  Y  POE  Config 

3 


Edit  Limits  Stores  poe  facilities  used  by  each  fleet  and  configuration  combination 
Model  Only 


Model  Datatype 


poefac 


poevehdata 
poevehf  leet 
poedelay 


data  is  current 


Domain | Lookup  B|V  Unit  Meas  Description 


CARGCONF 

FACILITY 


Hour sDe lay 


Planning  fleet  used  to  move  from  a  POE  node 
during  planning 

Cargo  configuration  carried  by  the  fleet 
Facility  used  by  the  fleet  and 
configuration  combination  (the  extra  record 
NFACILITY+1  is  specified  if  facility  is 
undetermined) 

Matching  record  in  the  VehData  table  used 
at  the  POE  in  planning 

Matching  record  in  the  VehFleet  table  used 

at  the  POE  in  planning 

Delay  occuring  at  the  facility  for  the 

cargo  using  this  fleet  and  configuration 

Flag  to  mark  that  the  poefac  data  is 

current 


Edit  Limits  I  Each  record  has  information  about  a  requirement  and  cargocategory  that  doesn't  depend  on 


Requirement  Category  Model  Only  measure. 


#  K?  Field  Name 

■  i 


1  Y  Requirement  Id 

2  Y  Cargo  Category 


ROUTE CAP 
Route  Capacity 


#  K?  Field  Name 


Model  Datatype 


reqqntot 
f irs t reqcatquan 


Domain | Lookup  B|V  Unit  Meas  Description 


Record#  BigSt 
CARGO CAT 

Long>=0 

REQQUAN 


The  requirement  identifier 

A  cargo  category  associated  with  this 

requirement 

The  total  amount  of  cargo  for  this  category 
in  its  basic  unit  of  measure 
First  requirement  quantity  for  this 
requirement  and  category  pair 


Edit  Limits  Lists  the  capacitated  link  used  by  each  route 
Model  Only 


Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 


1  Y  From  Node 

2  Y  To  Node 

3  Y  Route  Type 

4  Y  Vehicle  Is  Empty 

5  Y  Link  Capacity  From  Node  route cap_l ink 

6  Y  Link  Capacity  To  Node 


7  Y  Link  Capacity  Mode 

8  Route  Cap  Offset 


routecap_offset 


Record#  BigSt 

ROUTE 

ROUTE 

ROUTE 

NODELINK 


Long>=0 


Route  from  node 
Route  to  node 
Route  type 

Flag  for  empty  versus  loaded  travel 
From  node  of  the  matching  capacitated  link 
used  by  this  route 

To  node  of  the  matching  capacitated  link 
used  by  this  route 

Transport  mode  of  the  matching  capacitated 
link  used  by  this  route 

Distance  to  the  end  of  the  route  or  to  the 
next  capacitated  link,  in  nautical  miles 
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Directory  Type :  Model 


RTSTATE 

Edit  Limits 

Stores  dynamic  programming  states  for  shortest  path  routing 

Routing  Node  State 

Model  Only 

#  K?  Field  Name 


Model  Datatype 


Domain | Lookup  B|V  Unit  Meas  Description 


1  Y  Route  State 


rtcost 

rtpred 

rtpredlink 

heaproute 

onrouteheap 

rtrange 


Record#  BigSt  Yes 

Long>=0 

RTSTATE 
Short >=0 

RTSTATE 

Short >=0 

Long>=0 


Routing  node  number  but  can  be  extended  to 
include  post-destination  refueling  recovery 
bases 

Cumulative  cost  plus  lower  bound  of 
achieving  this  state 

Predecessor  state  in  reaching  this  state 
The  link  used  to  travel  from  the 
predecessor  state  to  this  state 
Priority  queue  of  routing  states  for  the 
dynamic  programming  algorithm 
On  queue  status  index  for  this  routing 
state 

Cumulative  distance  since  the  last 
refueling 


UNITMEAS 

Major  Unit  Measure 

Edit  Limits 
Model  Only 

Lists  whether  a  major  unit  has  requirement  quantities  using  a  reporting  measure 

#  K?  Field  Name 

1 - 1 - 

Model  Datatype  Domain | Lookup  B|v  Unit  Meas  Description 

_ 1 _ _ _ i _ 1 — . — 1 - 1 - — - — * - 

X  Y  Major  Unit 

2  Y  Cargo  Measure 

3  Is  Major  Unit  Measure?  ismajunitmeas 


MAJUNIT 

RPTMEAS 

Yesflag 


IvjdJ  UX  U11J.U 

Cargo  quantity  measure  (ston,  pax,  cbbl, 
mton,  sq  ft) 

Flag  set  to  True  if  the  major  unit  has 
requirement  quantities  which  utilize  this 


VCPTFULL 

Edit  Limits 

Stores  in  the  model  the  first  matching  compartment /measure  in  VCPTMEAS,  if  any,  for  each 

Veh  Cpt  Type  Full 

Model  Only 

full  combination  of  vehicle  type  and  compartment  type 

#  K?  Field  Name 

i _ 


Model  Datatype 


^  Domain { Lookup ( B 1 V ( Unit  Meas  ^ 


Description 


1  Y  Vehicle  Type 

2  Y  Compartment  Type 

3  vcptmeas 


VEHTYPE 

CPTTYPE 

VCPTMEAS 


Vehicle  Type 

Name  of  an  available  compartment  type  for 
the  vehicle  type 

First  matching  compartment /measure  record 
in  VCPTMEAS,  if  any,  for  this 
vehicle/compartment  type  (zero  if  the 
compartment  type  does  not  exist  on  this 


vehicle  type) 


VCPTMEAS  Edit  Limits 

Veh  Cpt  Meas  Full  Model  Only 


Accumulates  compartment  measure  quantities  for  a  single  vehicle  during  route  insertion 
in  the  model  (also  tracks  total  vehicle  tonnage  in  the  extra  dummy  record) 


#  K?  Field  Name  Model  Datatype 

l - 1 - — - 

1  Y  Vehicle/ Cpt/Meas  Number 

2  Vehicle  Type 

3  Compartment  Type 

4  Compartment  Measure 

5  cptcurqn 


6  cptmaxqn 

7  cptpoeqn 


8 


cptpoemaxqn 


9 


cptcap 


Domain | Lookup | B [ V  <  Unit  Meas 

Record#  VehCp 

VCPTTYPE 

VCPTTYPE 


MEASURE 

Long>=0  Q 

Long>=0  Q 

Long>=0  Q 

Long>=0  Q 

Long>=0  Q 


Description 

Compartment/measure  record  number  for  a 
single  vehicle 

Vehicle  type  for  the  current  vehicle 
Vehicle  compartment  type  for  the  current 
vehicle 

Compartment  measure 

Running  total  of  the  compartment  measure 
quantity  after  leaving  the  predecessor  stop 
on  its  way  to  the  insertion  stop  (extra 
record  is  used  for  total  vehicle  capacity, 
so  cannot  size  by  vcptcap  alone) 

Maximum  compartment  load  encountered  on 
vehicle  during  insertion  of  a  new  cargo 
Total  of  the  vehicle  compartment  load  prior 
to  the  inserted  POE  stop  (used  to  try  later 
on  POE  insertion) 

Max  compartment  load  encountered  prior  to 
the  inserted  POE  stop  (used  to  try  later  on 
POE  insertion) 

Capacity  of  the  vehicle  compartment  in  this 
measure 
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Directory  TyPe :  Reference 


CLASSIF 

Classification 

Edit 

Limits 

Lists  the 

various  security  classification  levels 

q  K?  Field  Name 

Model  Datatype 

( Domain | Lookup  j  B | V  ^  Unit  Meas 

Description 

1  Y  Security  Classification 

2  Security  Classif  Code 

A12 

A1 

Classification  level 

Classification  abbreviation 

MAPCOLOR 

Mapping  Colors 

Edit 

Limits 

Lists  the 

available  colors  for  mapping  objects  (shapes  and  lines) 

#  K?  Field  Name 

Mode 

;1  Datatype 

Domain | Lookup  B|V(Unit  Meas 

Description 

1  Y  Color 

2  Red  Intensity 

3  Green  Intensity 

4  Blue  Intensity 

A15 

Byte>=0  Yes 

Byte>=0  Yes 

Byte>=0  Yes 

Name  of  the  color  for  mapping 

Red  intensity  for  the  color 

Green  intensity  for  the  color 

Blue  intensity  for  the  color 

MAPFILE 

Map  File  Paths 

Edit 

Limits 

Lists  the 

world  map  file  paths 

#  K?  Field  Name 
l _ 1 - 

Mode 

i 

si  Datatype 

Domain | Lookup ( B | V ( Unit  Meas 

Description 

J - — - 

1  Y  Map  Name 

A20 

2 

Map  Drive 

A1 

3 

Map  Workspace  File 

A50 

Yes 

4 

Description 

A50 

Yes 

5 

Application  Title 

A50 

Yes 

6 

Map  Window  Title 

A50 

Yes 

7 

Map  Browse  Table 

A50 

Short  name  for  the  world  map 
Drive  letter  for  the  map  data  (may  be  a 
CDROM) ,  updates  the  workspace  file  if 
changed 

Full  path  or  path  relative  to  Mapapp  for 
the  world  map  .wor  workspace  startup  file, 
usually  in  Mapapp  and  not  on  the  map  drive 
itself 

Description  of  the  world  map 

Title  displayed  at  the  top  of  the 

application  window  as  a  whole 

Title  for  the  world  map  window  within  the 

application  window 

Full  or  relative  path  without  drive  letter 
to  a  general  map  browse  table  (Maplnfo 
*.tab  file)  located  on  the  map  data  drive, 
blank  if  none 


MAP FONT 

Mapping  Fonts 

Edit 

Limits 

Lists  the 

available  fonts  for  mapping  labels 

#  K?  Field  Name 

Mode 

i 

si  Datatype 

Domain | Lookup ( B | V  ^ Unit  Meas 

Description 

1  Y  Font  Name 

A50 

Windows  Font  (or  Maplnfo  Helvitica, 

Courier,  Times) 

MAPFSTYL 

Mapping  Font  Styles 

Edit 

Limits 

Lists  the 

font  styles  for  mapping  labels 

#  K?  Field  Name 

Model  Datatype 

i 

Domain | Lookup ^BlV^Unit  Meas 

Description 

1  Y  Font  Style 

2  Style  Value 

A25 

Short >=0  Yes 

Name  of  Font  style 

Maplnfo  value  for  this  Font  style 

MAPLINE 

Mapping  Line  Types 

Edit  Limits 
Constant  No 

Lists  the 

available  line  symbols  for  map  links 

#  K?  Field  Name 

Model  Datatype 

i 

Domain | Lookup ( B | V ( Unit  Meas 

^ Description 

1  Y  Line 

2  Line  Value 

A25 

Byte>=0 

A  line  type 

The  Maplnfo  numeric  value  for  this  line 
type 

MAPSHAPE 

Mapping  Shape  Types 

Edit 

Limits 

Lists  the 

available  shape  symbols  for  map  nodes  using  installed  Windows  fonts 

#  K?  Field  Name 
|  1 

Model  Datatype 

i 

^ Domain | Lookup ] B | V  ^  Unit  Meas 

( Description 

1  Y  Shape 

2  Character  Value 

A25 

Byte>=0 

A  shape  type 

The  Maplnfo  numeric  value  for  this  symbol 
shape 

The  font  name  of  a  symbol  shape 

The  font  style  for  this  symbol  shape  and 
character  value 

3  Font  Name 

4  Font  Style 

MAP FONT  Yes 

MAPFSTYL  Yes 

MAPTYPE 

Mapping  Table  Types 

Edit  Limits 
Constant  No 

Lists  the 

fundamental  mapping  table  types  (Node  or  Link) 

#  K?  Field  Name 
|  | 

Model  Datatype 

( Domain | Lookup  ^ B | V  ^ Unit  Meas 

^ Description 

1  Y  Map  Type 

A10 

Available  mapping  display  types 
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